C H A P T E R  6

Team Development

Team Development is a lightweight project governance tool that fits hand-in-glove with the APEX software development framework and Agile software development. Team Development is an integral part of the APEX software development framework; therefore the developers and other stakeholders do not have to spend time with inefficient context switching between APEX and an unrelated project management tool. Team Development directly complements the Agile software principles, minimizing the necessary and sometimes tedious project governance overhead.

APEX teams who take advantage of Team Development will reap the tangible rewards of increased company profitability and more personal free time—free time that can be spent on the truly important things in your life, like personal mental health, personal physical health, your family, and your social network.

Team Development consists of five modules:

• Feedback
• Features
• To Dos
• Bugs
• Milestones

Feedback is an APEX mechanism that encourages all stakeholders to collaborate with the developers in the development process. A feedback link is built into every page in an APEX application, making it quick and easy for any user to make suggestions, float ideas, and report bugs. The Feedback mechanism is built into the APEX framework; therefore it captures the user's comments plus the application's context at the time the comment is made. The latter point is invaluable to the developers. I believe that the Feedback mechanism is incredibly important because it directly supports Agile's emphasis on “customer collaboration.”

Features are a list of high-level artifacts that are valuable to the project management process. The list of features tells everyone “what” is being built.

To Dos are a list of low-level tasks that assist a self-organizing team to stay organized. The team figures out what work needs to be done in order to build a feature. The work is captured in the list of to-dos; developers then check out the to-dos and work on them. The list of to-dos tells everyone “how” a feature is being built.

Bugs are kept in a list that is separate from the features and to-dos. The separation allows the bug-fixing life cycle to be handled in a versatile manner. Simple bugs are fixed quickly with no need for long-term tracking. Complex bugs may have a life cycle that spans several product releases; these might need to be tracked using a feature or a set of to-dos.

Milestones are used to coordinate the project's timeline. Features, to-dos, and bugs can all be associated with a milestone; this association is the basis for an effective report that lets everyone know what is being delivered and when it is being delivered.

Team Development was introduced to APEX in version 4. Its introduction as a marquee module is a clear sign that APEX is maturing with age. Oracle's APEX team used Team Development to manage the development of APEX version 4. Since the APEX team “ate its own dog food” by using the tool, you will find that Team Development is practical and robust.

Feedback

Team Development's Feedback module is powerful. Its power shows itself when it is used aggressively throughout a project's life cycle as a catalyst for collaboration among all of the stakeholders (see Figure 6-1). The Feedback module allows everyone who is involved with the application to quickly and easily capture an idea or flash of insight while remaining within the application's context. Remaining in the application's context allows the user to record an idea without having to navigate away from the application to go to an unrelated system. I personally have difficulty with context switching; often when I switch contexts, I lose my train of thought and the idea is lost or becomes muddled. All ideas and suggestions are recorded in the feedback repository, where everyone with the development role can review and comment on them; this is a significant benefit over having the ideas spread across several platforms. Remember, this type of close collaboration is a key cornerstone of Agile software development.

The return on investment (ROI) for Team Development's Feedback module is almost infinite. The investment time is measured in seconds or minutes, while the return time is measured in days, weeks, and potentially months. Feedback is deceptively simple, and its simplicity tends to mask its potential power.

Traditionally, many of us have viewed software feedback mechanisms as channels for reporting bugs and problems. This is a negative view that probably has its roots in our experiences with help desk ticket applications. Team Development's Feedback module is not just another help desk ticket application. It is much more. It empowers everyone who touches an application to collaborate on building better applications and better business processes. Feedback enables all of the stakeholders to share ideas from within an application, where all of the application's context is available. Feedback acts as an efficient and effective repository for the following:

• Bugs
• Problems
• Questions
• Constructive criticism
• Suggestions
• Ideas
• Insights
• Flashes of brilliance

Figure 6-1. Feedback, the collaboration hub

The Feedback module can be used by the following:

• End users
• Help desk
• Training teams
• Sponsors
• Project manager teams
• Business teams
• Test teams
• Development teams

End users typically use an application frequently. They are the ones who are irritated by seemingly minor inefficiencies in a graphic user interface (GUI). Minor inefficiencies that add only two or three seconds to a process represent major cost savings for an organization when the two or three seconds are multiplied by several thousand users performing the process ten times a day. For example, the cost of a two-second inefficiency times two thousand users times ten inefficiencies per day times two hundred days per year times fifty dollars per user-hour times one hour per sixty seconds is over six and a half million dollars. It pays big dividends to listen to your savvy end users.

The help desk is uniquely positioned to recognize patterns in end-user behavior. Over time, the help desk can identify solutions to issues that come to them repetitively.

Training teams typically produce screenshots for their training documentation. In doing so, the training team looks at an application with fresh and critical eyes. Inconsistencies in flow and terminology, when they are found and corrected before an initial release, can reduce training time and the number of calls that are directed to the help desk.

Sponsors live in the strategic world. Project managers are concerned primarily with cost, schedule, and quality targets. Both teams will appreciate the timely and efficient reporting capabilities of the Feedback module.

The business and test teams are the first groups that get their hands on a new release of an application. They are heavy users of the Feedback module during the application construction. Both teams run the application looking for business and technical defects. When a defect is found, the Feedback module provides a fast, immediate, and accurate communication channel that enables the developers to respond quickly with a minimum number of follow-up calls and e-mails.

The business and test teams look at software products from an outside-in perspective, which is very different from a developer's inside-out perspective. The Feedback module helps to reconcile the two different perspectives through constructive collaboration.

Developers themselves are heavy users of the Feedback module. Often, a developer is working on a task and spots an issue. The Feedback module allows the developer to document the issue immediately together with all of the underlying context and session state data. The developer then continues with the task at hand with almost no interruption in the current workflow. The new issue is completely recorded in the feedback repository, where the team lead can review and classify it so that it can be addressed.

The User Perspective

From a user's perspective, the Feedback module is simple, intuitive, quick, and easy to use. A link to the Feedback page (see Figure 6-2) is automatically added to every page in an application when the Feedback module is installed and enabled.

A pop-up Feedback page (see Figure 6-3) is displayed when the user presses the feedback link. On the pop-up Feedback page, the user enters a description of the bug, problem, constructive criticism, suggestion, idea, insight, or flash of brilliance in the feedback text area. The user enters the optional data and then finishes the process by pressing the Submit Feedback button. All of the data that is visible on the page is saved to the Team Development repository together with a wealth of “under the hood” information that is invaluable to developers and impossible to capture from the users via phone or e-mail.

Figure 6-2. Feedback link on an application page

Figure 6-3. Feedback pop-up page

Feedback Flows

The previous section shows how easy it is for end users to add feedback to the Team Development repository. We will now look at the bigger picture to see how feedback and responses flow back and forth between the stakeholders.

Team Development and its Feedback module are tied to individual APEX workspaces (see Figure 6-4). Feedback data is copied from one workspace to another by the APEX import/export utility, which is used to export feedback from one workspace and import it to another. The import/export facility for feedback is identical to the familiar import/export of APEX applications (see Figures 6-5 and 6-6). The export facility creates a single file that is copied to the target environment where it is imported.

Feedback generally flows from production to test and finally to development. Responses flow in the reverse direction and can be transmitted by using the response entity that is built into the Feedback module or via e-mail to individuals or entire teams. Repetitive responses can be published on a company intranet; often the help desk is responsible for publishing repetitive responses.

Each workspace should have a feedback moderator. The moderator has a first look at all new feedback entries and is responsible for classifying individual feedback entries so they can be routed to the appropriate team.

Figure 6-4. Feedback flows

Figure 6-5. Export team development feedback

Figure 6-6. Import team development feedback

Feedback in the Development Workspace

Self-organizing teams can use the Feedback module to great effect during the development sprints. Individual developers are generally smart, skilled, creative, and motivated to excel. The Feedback module gives the developers a tool where a quick flash of insight can be captured and shared almost instantly with the rest of the team. Once the new insight is captured by the Feedback module, it is an item that can be put on the agenda for the next daily meeting or the next sprint kick-off meeting.

Feedback in the Test Workspace

The test workspace is home to a number of teams outside of the development sphere. I would suggest that the business team moderate this instance of the Feedback module because the business team is in the best position to classify feedback in light of the business requirements.

The test team's mandate is to run scenarios against the application to find both technical and business problems. I have had the pleasure over the years of working with a number of highly skilled and successful test teams. One thing they all had in common was a time-consuming and sometimes difficult communication process with the development team. Often, the testers captured screenshots and wrote lengthy descriptions of an issue. These communications were transmitted to the development team via an e-mail or a quality assurance application and often left out data that was critical for the development team. When critical data was left out of a communication, the issue resolution needed several back-and-forth e-mails and phone calls with a developer. In many cases, the developer could not reproduce the issue and had to leave the issue open until the issue reared its ugly head again in the future. This is never an ideal situation.

The Feedback module short-circuits the communication gap between the test and development teams. All of the APEX session state is captured in the Feedback module; therefore, laborious screenshots are not required. Feedback often gives the developer all of the data needed to re-create an issue in the development workspace.

The business team and sponsors are interested in making sure that the application fulfills all of the business requirements. Questions and observations concerning business rules, usability, and workflow are ideal inputs to the feedback repository.

Feedback in the Production Workspace

The production workspace is home to the end users. Feedback from the end users concerns itself primarily with training and business questions. The production feedback moderator could be the help desk or the business team, and, in most cases, the feedback would be answered immediately within the production context.

Occasionally, a production issue could be transported to the test workspace, where a more complex issue would be re-created and analyzed. If necessary, the issue can be passed on to the development workspace if changes to the application are required.

Feedback in a Project Life Cycle

Feedback usage varies significantly over a project's life cycle (see Figure 6-7).

When APEX is used as a prototyping tool, the Feedback module is used to facilitate collaboration between the development and business teams. The development team will generally cobble together a rough idea of how the application should look based on their first understanding of the business requirements document. The rough idea is often very rough and requires a lot of input from the business team. In the prototype, the overall navigation strategy is designed together with high-level process flows. As more modules are prototyped, more feedback is required. At this stage, one must remember that the Feedback module is merely a tool that supports the people. It is still important for the teams to meet face-to-face during this stage in the project life cycle. Often, feedback entries will be made at times when the developers and the business team are sitting side-by-side. These feedback entries capture design decisions and can act as concise and effective meeting minutes.

Feedback usage remains very high when the first version of the working software is delivered to the test workspace. Here, the test team joins the fray. At this point, the test team will aggressively use the Feedback module to document technical and business defects. The business team will second-guess some of the decisions that were made in the prototype; often a few areas in the prototype will be re-worked after the working software shows that the original design is actually a bit awkward to use. This is a natural example of the iterative and agile nature of software development.

As development unfolds through multiple iterative sprints, feedback usage should decline. This is due to the fact that the business team progressively learns more and more about the capabilities of the development team and the development tools. It is also due to the fact the development team learns more and more about the business environment. The progressive learning on both sides makes each iterative sprint more productive because more and more software is delivered defect-free.

When the first release is delivered to production, there will be an initial flurry of feedback activity while the end users come up to speed. This activity declines rapidly and settles to a low level that comes from new end users and the occasional insightful suggestion from a savvy user for an incremental improvement.

Figure 6-7. Feedback usage over a project's life cycle

Team Development Architecture

Team Development is simple, extensible, and flexible. These properties make it an ideal fit with Agile.

Simplicity, which is one of the twelve underlying principles of Agile, is illustrated in Figure 6-8. There are only six major entities: Features, Milestones, To Dos, Bugs, Feedback, and Response. Each entity has a rich set of attributes that are used to manage and track the development of a product and the progress of the related project. Simplicity makes it easy for a team to keep the Team Development repository up to date as the work on an application progresses.

Workspaces can contain one or many applications. When many applications are developed in a single workspace, Team Development's usage of interactive reports makes managing multiple applications relatively easy by allowing the users to filter the Team Development repository by application. The filtered reports can be saved; this allows users to customize their Team Development environment to suit the users' roles. For example, a developer could have two reports listing to-do items, one that lists the tasks that have been assigned to her and one that lists the tasks that have been assigned to the team. The ability to quickly customize reports to suit specific needs supports Agile's principle of self-organizing teams.

Figure 6-8. Feedback—simple

Features and To Dos both can have children, grandchildren, great-grandchildren, and so on (see Figure 6-9). This feature makes Team Development extensible. Features, which are used to describe the product, can be subdivided many times as a high-level design becomes more and more detailed. Eventually, a point is reached where all of the features that describe a product are clearly listed and articulated. Those of you who choose to use feature-driven development as your Agile methodology will find the Team Development's Features module to be a comfortable fit.

The extensibility of To Dos is analogous to Features. An individual task can be broken down into its sub-tasks. This allows a team lead to manage the team efficiently and effectively.

Figure 6-9. Feedback—extensible

Team Development's flexibility is illustrated in Figure 6-10. The entities can be interrelated in many ways. Teams can tailor the interrelationships to their specific needs and styles of getting the work done.

Figure 6-10. Feedback—flexible

You might question the need to use all of the entities and relationships in Team Development. The question is a good one because Agile values results more than process. Figure 6-11 shows an extreme programming view of Team Development. In this case, a team has taken the strategic stance of doing the simplest thing that will work. It shows that it is possible to govern a team by using only the Feedback and Feature entities. I don't recommend this as a best practice; it merely illustrates one of many strategies that teams can devise to govern their software development efforts.

Figure 6-11. Feedback—extreme

Features

Features have two main goals. First, they are used to describe the product that is to be built. Second, they are used to track the project's progress.

Features are used at the beginning of a project to describe the high-level things that a software product must do. The initial high-level list of features is the first attempt by the development team to translate a business requirements document into web pages on top of an underlying database. The list of features is expanded to the point where budgetary estimates can be made of cost, schedule, and resource requirements. Agile values responding to change over following a plan; however, the plan has value. In fact, the initial high-level plan is mandatory for getting the money, resources, and permission to start the project. At this point, you hope that the budgetary estimates are robust enough to accommodate the inevitable plan changes that Agile predicts will happen.

Agile uses working software as the principal measure of progress. Features divide the software product into pieces that are the visible building blocks of the software product. As each feature is completed, concrete progress is reported to the sponsor and, more importantly, demonstrated to the sponsor.

Agile encourages “sustainable development, able to maintain a constant pace.” This Agile principle guides the amount of subdivision that is applied to features. You want to be able to complete one or more features within a single two- to four-week sprint. Right-sizing the features so that they fit within the sprint time boxes enables the development team to work with a sense of steady rhythm and gives everyone a sense of progress and accomplishment. Progress and accomplishment are key motivating factors for the development team as well as the other stakeholders.

Milestones and Releases

A key Agile principle that is shared among all of the lightweight methodologies is “ working software is delivered frequently (weeks rather than months).” Milestones and releases are ideal tools for scheduling regular delivery of working software to both the test and production environments.

Milestones can also track other events that are not directly associated with a sprint—for example, a key milestone could be the delivery of hardware that is part of a project. However, in the Agile context, a milestone's chief duty is to define a scheduled release.

Milestones and releases are closely related in Team Development. They often describe the same event. Milestones have metadata that describes the milestone event. Releases, on the other hand, are merely labels that are used to filter Team Development reports. I have found that giving a milestone and its related release the same name helps organize this area and minimizes confusion among the developers and stakeholders (see Figure 6-12). In an environment that contains many applications, it can also be helpful to add an application prefix to the milestone and release names. This strategy helps keep reports explicit and clear.

Figure 6-12. Milestone and release naming suggestion

Features, to-dos, and bugs have their due dates. Do not confuse or mix the due dates with the milestone dates. Most often, the due dates are set well in advance of the milestone's date.

To-Dos

To-dos are tasks. To-dos, like features, can be subdivided into child and grandchild to-dos. To-dos are subdivided until the lowest level where reportable control is exercised.

Two of the Agile principles are supported directly by to-dos: “projects are built around motivated individuals, who should be trusted” and “self-organizing teams.” Teams have a meeting at the beginning of each sprint or iteration. During this meeting, the team decides which to-dos are to be attached to the sprint's release milestone. Once the list is finalized, it becomes the sprint backlog. Developers decide among themselves who will take on individual to-dos. The developers check out their to-dos and begin work. The daily stand-up meeting is used to constantly check progress and quickly identify any to-do that is giving someone trouble.

On average, most to-dos should require no more than a few hours to complete. Occasionally, a to-do might require several days. Team Development's to-do technology accounts for longer to-dos by tracking percentage complete and status. The overhead involved in administering the to-dos is minimal due to the fact that a link to the developer's list of to-dos is embedded in the APEX Application Builder. Check-in and check-out in this efficient environment take but a few seconds.

To-dos have a progress log that is handy for situations where more than one developer works on a to-do. The progress log acts like a diary where developers can leave notes and technical suggestions to one another. This is handy when the developers are not co-located and are in different time zones.

Bugs

Bugs are a painful fact of life. Bugs come from two main sources. The obvious source is a coding error due to a mistake or a misunderstanding of a business requirement. The other main source is an error in the business requirements document or in the underlying design.

Coding errors, when found, are generally easy to fix. In the Team Development environment, a simple bug is attached to a single to-do. The to-do is attached to a release. The to-do pops up in the release's sprint log, and a developer assigns it to himself. The fix is made and published with the next application release.

Errors in the requirements or design are potentially more problematic. Sometimes the solution requires changes to the application's entity relationship model, which, in turn, ripple through the application pages and workflow. The solution might span several sprints when the changes are large. This situation can be managed effectively by attaching the bug to a single parent to-do. The detailed work is meted out to child and grandchild to-dos that can be released over several sprints.

Developer Workflow

The Team Development repository, when it is kept up to date, is an effective and efficient source of information for all of the stakeholders. Two features of Team Development make it easy for the developers to keep Team Development up to date and make it easy for all stakeholders to extract the information that they need.

Developers are able to easily keep the Team Development repository up to date because Team Development is embedded intimately in the APEX Application Builder. Figure 6-13 illustrates the upper-right area of an APEX edit page. There are four links to the to-do, bug, feedback, and comment pages in Team Development. Clicking one of the links takes you directly to the related Team Development interactive report that is pre-filtered to the current development context (see Figure 6-14). The quick and convenient navigation between APEX's Application Builder and Team Development makes keeping the Team Development repository up to date a painless task that can easily be done in real time as part of a developer's hourly workflow.

Figure 6-13. Team Development is intimately embedded in the APEX Application Builder.

Figure 6-14. To Do page pre-filtered with the context from the Edit page

Reporting

Team Development's repository is exposed through interactive reports. This is not a trivial statement. Interactive reports allow all of the stakeholders to easily customize a set of reports that are meaningful to their work.

Developers will quickly build interactive reports that show their personal to-dos for the current sprint. A report showing the sprint backlog allows them to quickly take charge of their next to-do. Team leads or scrum masters probably will customize reports for both the sprint backlog and the product backlog.

Progress reports are of interest to the sponsor and business teams. Progress reports can be customized for both groups by using the interactive report on the Features page.

Figure 6-15 shows you the to-do report's default columns on the right-hand side of the shuttle. The left-hand side of the shuttle contains all of the other metadata that is available for inclusion in the report. All stakeholders, with a small amount of training, will quickly learn to build the reports they need for their daily, weekly, and monthly reporting and workflow control needs.

Figure 6-15. To Do interactive report, customization possibilities

Summary

Team Development is a lightweight project governance tool that is ideally suited to an Agile approach to APEX software development.

The Feedback module, when used aggressively by all stakeholders, is an ideal collaboration tool that enhances the Agile principle of “close, daily co-operation between business people and developers.” The Feedback module can be used as a catalyst for collaboration throughout the entire software development life cycle, from proof of concept to prototype to development to testing and validation to production.

Team Development is embedded in the development fabric of APEX. This framework's convenient and efficient navigation strategy makes it extremely easy for developers to keep the Team Development repository up to date on a real-time basis. Meaningful reporting, therefore, is a snap for the entire community of stakeholders.