GLUE Roles and Responsibilities

In my last post about GLUE Delivery I have put some focus on the delivery which is from my point the key for everything I do. Deliver, Getting things done, create something, add something. You name it.

“Trifles make perfection, and perfection is no trifle.”,
Michelangelo (1475 - 1564)

As I have tried to explain in my last post the GLUE Deliveries deliver the GLUE Deliverables. Quite obvious including a name generator for deliveries and deliverables. But who delivers, what are the roles and responsibilities? What does the statement "GLUE Deliveries are delivered by Responsible Roles" mean?

For the GLUE Roles I capitalize on the GLUE Disciplines by applying a generic GLUE Role to each Discipline:

1. The Stakeholder does deliver Describe Intention.
2. The Analyst does deliver Define Requirements.
3. The Architect does deliver Design Architecture.
4. The Developer does deliver Develop Solution.
5. The Operator does deliver Do Operation.
6. The Tester does deliver Detect Defect.

Similar as with GLUE Deliveries and Deliverables the full blown name can be constructed by applying a name generator approach: Role Name = Name of Deck + Name of Division + Name of Role for Discipline. By using this mechanic I can look into methodologies and map the corresponding roles into GLUE Roles to understand what basic techniques they must master to be able to deliver. That helps me in judging the CVs and people at hand when a new team member is offered or seeked for. That also supports me in looking into overlaps, because no matter what the official Job Title is, the GLUE Role, Delivery and Deliverable expresses what is done.

In the potential conflict between the Business Organisation and Enterprise Architecture which I explored in the GLUE Domains both, the Business Organisation and Enterprise Architecture do deliver Business Architecture. The challenging question of course is which organisational element does do what part of the delivery.

To support GLUE Journeys which I will touch in a future post I like to remind here short of responsible assignment matrix concept:

• Validating a Deliverable is done by Peers (same Role but not part of the Journey) and/or by those who receive the Deliverable.
• Verifying a Deliverable is done by Testers of the same GLUE Deck.
• Accountable for a Deliverable is the Owner of the GLUE Domain out of which the Deliverable is delivered, and this can of course be a Tailored GLUE Domain.
• Responsible is the corresponding Role as describe in this post.
• Informed is every Role which needs the information.
• Supportive is the Peers (same Role).
• Consulted is some Peers (same Role) who do not actively take part in the Journey.
• The general advice from me is to utilize collaborative approaches over cooperation approaches and try to prevent non-cooperation mode. Sometimes tough to achieve, but advisable to aim for. Most methods actually are only designed around cooperation approaches.

In my next post I like to explore the GLUE Journey concept to show how all of this ties together. As always please comment if you have the desire to do so. If not I will continue following my own path through my own thoughts with some difficulties to understand if I am still on track (understood by anyone) or totally lost in my own ideas. Well, they work for me, so at least that is kind of ok. :)