Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Online Collaboration & Agile Software Development Iteration Before Online Collaboration Online Collaboration

Iteration Before Online Collaboration

Before the availability of online collaboration tools, preparation for iteration planning meetings started with the project owner prioritizing the product backlog to identify which features or enhancements had the highest priority. The project manager then made a high-level estimate on the features, and set up an initial plan for the next iteration. For instance, a typical iteration might have included adding a few simple features and improving the performance:

• Add two new fields—a conference phone number and conference code—to the Scheduled Online Collaboration Meeting (the "Session").
• Improve application performance when users cast votes on a ballot. Using ThinkTank, the collaborative tool from GroupSystems (the company I work for), people can vote on ballot items to evaluate ideas and build consensus. We wanted to speed up the response time when people cast ballots.
• Move the "Report" button to another section of the application so it could be more readily accessed. (After completing an online collaboration session in ThinkTank, you can generate and send a report to participants who attended the meeting. We wanted everyone to be able to generate their own report.)

Once the project manager knew the features identified in this iteration, he reviewed the features during the week with team members. This gave the team a general idea of what was coming in the next iteration. Quite often, team members were so busy they didn't have time to review and clarify the requirements of planned features. Consequently, review and clarification was left for the iteration planning meeting.

For the meeting, stakeholders dialed into a conference phone number so that each person could participate. The first part of the meeting was always energetic. The development team gave demonstrations of what they had accomplished during the previous iteration. Once the demonstrations were complete, the project manager and product owner reviewed what was completed in the previous iteration and what improvements to make for the next iteration.

The next step in the iteration planning meeting was reviewing upcoming features. This review took a bit of time. As the product owner reviewed each feature, requirements questions invariably came up. Each question was clarified and laboriously documented, one at a time.

• "Where do fields get added?"
• "Where exactly does the performance problem occur? When all people cast ballots at the same time? Or when one long ballot is cast?"
• "Where should the Reports button go?"

Remote team members strained to hear the questions, and had a hard time getting their questions across through the phone. Sometimes team members didn't think the feature being reviewed applied to them, so they stopped paying attention. After the review process, the team was drained and not as receptive to identifying and estimating their tasks.

This is only one example involving three features. As you can imagine, when an iteration had a large number of complex features, the process took a long time.

The next step in the iteration planning meeting was adding tasks. Each person communicated the tasks to the project manager so they could be documented. Again, this slowed the meeting to a crawl. On the conference phone, you could hear remote members answering e-mail or doing more development.

After tasks had been estimated, the team decided whether all of the features could be accomplished in this iteration. In this example, the team thought that the project manager made a good initial guess at what could be accomplished, and that they could accomplish all of the originally planned features for this iteration.

By the time the final review was done, the team came up with the following list of initial tasks and assigned them to team members:

For Additional Fields:

• Update the session object with additional fields to add some requested features to the product. (Joe)
• Update test cases. (Joe)
• Add additional fields for the session to the database. (Brian)
• Update the GUI. (Steve)

For Improving Performance

• Determine where the performance was slowing. (Jes)
• Make necessary changes. (Jes)

For Moving the Reports Button

• Move the Reports button. (Steve)

Overall

• Notify customers of our new updates.

As the iteration progressed, Steve proceeded to add the fields to the GUI. He knew which screens, but didn't know exactly where on the screens to put them. Since the product owner wasn't around, he made his best guess. Quality assurance reviewed the updates and checked with the product owner. As it turned out, Steve guessed wrong and had to move the fields to the right place. This lack of clarity in the requirements caused some time delay to coordinate the product owner, quality assurance, and developer. It also took Steve time to put the fields correctly in the GUI a second time.

Steve also noticed that the new fields needed to be added to another place in the application—the e-mail invitation. Putting the conference phone number and the conference code on the e-mail invitation made accessing and starting an online collaboration session easier, but added a few more unaccounted for tasks.

Meanwhile Jes continued to work on his tasks. Although he struggled with the performance improvements, he made major strides. Still, the improvements weren't quite enough and took longer than he thought. During one of the daily stand-up meetings, he brought this up and got some good ideas from other team members. However, he could have saved some time if this was brought up earlier.

Once he got the performance improved enough, Jes checked in his code, but it broke another part of the application: the reports. Steve found out late in the iteration that he needed more time to update his code to get the reports working again. More discovered work.

With all of these found tasks and other issues, we moved the "Move Reports Button" feature to the next iteration and, at the end of the iteration, had to notify management we weren't able to get all of the planned features implemented. Customers expecting the feature also had to be notified.

Obviously, this iteration didn't go smoothly:

• Requirements were not clear.
• Additional tasks were found.
• In the case of performance improvements, additional input from team members would have sped up development.

Previous Page | 1 Online Collaboration & Agile Software Development | 2 Iteration Before Online Collaboration | 3 Online Collaboration Next Page

RELATED ARTICLES OutSystems Updates Agile Platform Danube Releases ScrumWorks Pro 4.1 Agile Self-Evaluation Tool Released Why We Need a Theory for Software Engineering Nokia Takes Task Management For A Spin		TOP 5 ARTICLES No Top Articles.