Design Authority – Part two

21 11 2007

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

Your Design is AUTHORISED!!!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.

Advertisements

Actions

Information

One response

27 05 2012
Marty

Just came across this post……interested if you have had any follow up……the design authority role is something I’m interested in, particularly the challenges in operating one in a disparate agile environment without impacting team flexibility and velocity??

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: