Design Authority – Part two

Using the Design Authority concept in a large multi team agile environment.

I was speaking with a colleague not long ago. He was asking me about using agile in a large team (50 plus developers, testers and designers), and the kinds of

The challenges as we saw them were;

• That the software that the floor produced all serviced an internal client (i.e. the organisation).
• That development efficiency was anecdotally noted as being not where it was desired.
• That development consistency was also anecdotally not where it was desired.
• That because of the changing priorities, consistency was a real issue, both in the visual, experience and technical areas, affecting the perceptions of quality, reliability and repeatability.

So I spoke with him about how he could firstly consider using agile methods to enable flexibility in his teams, so they could be configured against the outcomes required of them by the clients. We discussed the use of a configuration manager role, which would effectively marshal those team configurations so that the teams were created and disbanded in an efficient manner. We also discussed how he could still use a predominantly linear management technique to run the floor from an administrative perspective, thus supporting regimented accounting and reporting responsibilities.

Lastly we discussed how he could use a ‘Design Authority Cluster’ to cover off the following key areas:

• Visual and interaction design
• Business modeling design
• Technical or architectural design

The versatility of the Design Authority role is such that the key concepts of having a dedicated role to maintain authority and provide that ‘single point of truth’, can easily be carried over consistently to pretty much any discipline. The only example where I can’t see it being applied, is in Project Management where a Centre of Excellence or PMO model is probably more appropriate.

Obviously the key points in actually considering these roles are:

• Actual benefits of consistency of approach
• Holistically as a whole does the development floor required to produce visually and technically consistent products?
• How many people will be needed to fulfil the role of the Design Authority, and will they be full time or part time or just plain over-time!?
• What is the cost of change to the behaviours and activities for development, planning, testing, release management and so forth to instill this new set of roles?
• Is it a single point of truth that’s needed or an expertise Centre of Excellence. (hint; one is about guidance and accountability, the other is about capability development and provision, and you may indeed need both.)

In large organsiations, predictability is a big thing. This is because it serves the accountability requirements which is a big deal, particularly in organiations that have public obligations or responsibility to shareholders.

The Design Authority role, engineered and embedded well into an environment can go a long way to supporting those needs.