Method for Open Dynamic ENgineering of Applications
Characteristics
MODENA differs from SCRUM primarily in the following ways:
no Storypoints, estimations and plannings are done in PDs
no Sprints, the items are permanently prioritized in queues
There are still estimation meetings, retrospectives, reviews and a product backlog. And there are queues.
There might be several competing queues. It's the TeamMasters job to merge the results of the queues into one MODENA queue. The development team will start with a bunch of items (transferring them from the product backlog to the MightBoard=MODENA white board[2]) and implement them.
If an item is finished (that means specified, implemented, tested and documented), the next item will be started. If a bunch of items is finished, a new bunch of items is transferred to the white board. Items which are not approved will stay on the board.
If at any time (in any test stage) a bug occurs, the current work is stopped and the bug must be fixed before continuing.
Consequences
Implementing the method should have the following consequences:
Instead of starting and stopping the development process and energy for every sprint, the queue mechanism allows a continuous and flexible prioritization of items.
The implementation of items can be requested without the need to wait for one sprint-cycle to end. 3 weeks before a new release, the process is stopped to allow the final testing and documentation.
Items must be approved by the item owners as soon as they are finished by the development team. MODENA is supposed to lead to an easier synchronisation between the teams. The queue mechanism allows a continuous and flexible prioritization of items.
This method seems to be better suited for the ongoing development of applications, that are delivered as releases. For smaller projects or projects with a definite end-date, Scrum still seems to be the method of choice. In any case, Scrum is an established development method, Modena is younger and has to prove itself within the field.
In our environment I suggest the Support team can try adopting this approach for CI activities.
Subscribe to:
Post Comments (Atom)

No comments:
Post a Comment