Daily cycle

The agile process Smart embraces a product life cycle. This cycle is used to track the progress of realizing individual products. By default this product lifecycle contains a small number of stage, depicted in the chart below, such as Stand Up, Design, Test Design, Code, Test, Rework, Accept. Clearly not all of these stages apply to all products in a project. Although a project plan is in rework often enough, hardly ever is a project proposal coded. So some deliverables do not go through all the stages in the cycle.

However, this product life cycle was designed to support the different activities that are executed to realize individual smart use cases. Smart use cases are analyzed, (test) designed, possibly (code) generated, built, tested and accepted. In most Smart projects this product life cycle is a daily cycle, as smart use cases are realized on a daily basis.

Daily cycle

The Smart daily cycle runs like this:

Stand up. Start the day fresh with a brief stand up meeting. Goal of this meeting is make sure everybody in the team is on the same wavelength. Monitor the progress, by having all team member report on what they did the day before, on what use case they will be working on today, and what possible gaps there are to realize this use case. Wave all discussions on functionality or technology to the next step.
Design. Discuss the use cases at hand. What is still missing? Is the use case description clear? Is the domain model correct? Do we no what's on the form? Don't forget to take notes.
Test design. The test design for the smart use cases at hand is set up. Find out which scenario's can get you through the use case steps, where exception scenario's are and whether these fail or can be repaired. Notably, we use activity diagrams in the more complex interactive use cases to discover the scenario's. This step can best be executed in collaboration between the user, the tester and the developer. Next the tester prepares test cases according to the defined test scenario's.
Code. Now the developers start to realize the software that implements the use case. Using the Accelerated Delivery Platform, the code generator Tobago MDA might be applied to generate most of this software, speeding development to a daily basis.
Test. Test the individual use cases according to the test design specified earlier. In most cases the tester does the job, but we've also seen projects were either the analyst or the end user takes care of testing use cases. If the tests pass, the use case moves to acceptance.
Rework. If its tests pass, but the smart use cases is not accepted by the end user, the use case goes to rework. Rework always has high priority, since it is preferable to finish individual smart use cases, rather than have a number of them half-baked. Plan and do your rework before starting new use cases. After that test them again.
Accept. Let the end user accept the individual smart use cases, preferably on a daily basis. If the acceptance is not agreed upon, move the smart use case to rework, and mark the work left to be done, e.g. in the project's dashboard.

Additional stages in the product life cycle¶

Sometimes projects skip a number of these stages, or apply additional stages to reflect the way the project is executed:

Analyze. Organizations that are used to a traditional distribution of responsibilities sometimes adhere to having a separate stage for analyzing the smart use cases. This activity is than performed by information or business analysts.
Team test. In distributed projects test activities are often split into two categories, depending on how actually performs the test. Team test is the first of these categories, and presents the work that is done by the(development) team around testing.
Customer test. In such distributed projects, the stage Customer test describes the effort the customer and end user put into testing. In classical projects, this effort is often referred to as acceptance testing.
Drop. A stage called dropped is used in quite a number of projects. Products are move to this stage when they will no longer be realized, in most cases based on the judgment of the customer or the end user.

It's a best practice to evaluate if the lifecycle is efficient for your project. Probably you want to define a more detailed lifecycle. Remember to keep the to get 1 use case realized! Possible extra stages could be: deploy to test environment, use case workshop with the team. But also more fine grained actions are possible: create unit test, update architecture document, define low level user interface design, developers test.

Robert de Wolff