Quick delivery of solutions via a PEAS-architected platform - mini-projects

This is a continuation of the post Quick delivery of solutions via a PEAS-architected platform" to describe functioning of mini-projects.

Roles within mini-projects (are taken from the DAD book)

A stakeholder is someone who is materially impacted by the outcome of the solution. In this regard, the stakeholder is clearly more than an end user.

The team lead (TL) is a servant-leader to the team, creating and maintaining the conditions that allow the team to be successful.

The product owner (PO) is the one individual on the team who speaks as the “one voice of the customer.” She represents the needs and desires of the stakeholder community to the delivery team.

The architecture owner (AO) is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design.

The role of team member (TM) focuses on producing the actual solution for stakeholders.

Solution elaboration

The preferable way for implementing solutions is assembling them from standard components available in the platform. Components are of the following types: Off-the-shelf functional extensions, e.g.

• plug-ins 
• Data structures and reports
• Documents and their metadata 
• Filing plans 
• Collaboration utilities (calendar, news, issues, etc.) 
• Business rules Roles and permissions 
• Processes (or workflows) 
• Tasks 
• Forms 
• Events and notifications 
• Layouts and presentations 
• KPIs 
• Audit trails 
• etc. 

The whole decomposition of a solution into components is also approved by the AO.

All components are versioned through their life-cycle. Component’s life-cycle is as usual: design v1, design v2, implementation v3, implementation v4, design v5, and so on. Versions of components can be produced by TMs with the help of secondary roles.

The last design version (i.e. before implementation) of a component must be approved by the AO.

The last implementation version (i.e. production) of a component must be validated by the PO with the help of stakeholders. TM proactively consults the PO about all components.

Thus the solution evolves as all its components are elaborated and a version of a solution is a snapshot of current versions of all its components. The PO with the help of stakeholders approves a production version of a solution. Each solution may have several production versions; in some case they may co-exist (i.e. overlap in time).

Some intermediate versions of the solution are actually prototypes which are throwable (« jetable » in French) by definition.

Time-boxing delivery

Mini-projects operate in a typical agile and goal-based iterative (like PDCA) way:

• Plan deliverables (a deliverable is a particular version of a component) for the current iteration. 
• Implement (do) selected deliverables. 
• Validate (check) completed deliverables with the product owner. 
• Act upon the feedback from the team. 

Thanks,
AS