The more people contribute to a team's output, the closer they should be to the team.

Everyone contributing to an IT project, ideally needs to be on the team responsible for delivery.  When this isn't possible, the more they contribute the closer they need to be to the team. 

The above point probably seems obvious to the point of being redundant to most people.  I'm sure that many teams (like mine) are structured with a healthy enough mix of skills that they can be mostly self-sufficient. With our team of testers, developers, infrastructure people etc etc I too would have thought we had this base more than covered. 

However, beware that contributors to a team's output come in many different guises.  I feel that we recently suffered on a project due to a key contributor being very distant from the team.

The project involved adding a new user journey to ft.com.  The UX team had designed a user journey, in isolation from the development team, which we were to implement.  The user journey that had been created was great, however, the team had another idea which involved less technical effort and might just get us in production (with that crucial real user feedback) sooner.

Thankfully, the product owner, project manager (and I think the UX team) were all open minded in considering the alternative user journey the team proposed.  After-all, the original flow could be added later as an enhancement after go-live.  The team set off in development with an aim of keeping both options open for a while, but the path of least resistance was clearly the original option and it was up to the team to persuade otherwise.

Sadly, mockups of the alternative flow were never created.  I suspect that, as a team, we felt out of place creating them ourselves as none of us wore the UX badge. We could have asked the UX team ourselves but given we didn't know them very well, they sat on a different floor and were outside of technology.  I suspect there were too many awkward hurdles for us to overcome.  Or, to reference Conway, the "organization's communication structure" did not (easily) allow it.

Eventually a decision had to be made and the original option was chosen.  After all, the original option was more "known" to people as it had been presented numerous times with mockups. 

As mentioned previously, the original (and chosen) user journey was good and I'm very pleased to say that it's currently live and being used well.  But I think we missed a trick by not giving the alternative user journey a fair chance.  This would have been more likely to happen had we been closer to the UX team.

Comments

  1. As you say, it seems obvious but I suspect it's a common complaint amongst Agile teams that require niche or occasional skill sets. I'd be very surprised if in the near future there isn't closer alignment between UX/Design and Technology. I wonder if there are other occasional skills that aren't a regular part of the team's makeup - traditionally DBA was one of these. The outstanding challenge would still be how to split this resource to be shared across multiple teams but to deliver timely changes.

    It also seems crazy that the team was pushed to a gold-plated solution rather than the Dev team's suggestion of a simpler initial deployment. I suspect the idea of iterating on a not-quite-complete app in a production environment is a cultural mindset that is slowly changing behind the engineering discipline of continuous deployment. Closer scrutiny of the ROI of any endeavour should help the case to deliver earlier.

    ReplyDelete
  2. Couldn't agree more.

    Maybe the UX resource for the project could come to the planning meeting and / or daily stand up when the stories involving design are played.

    ReplyDelete

Post a Comment

Popular posts from this blog

Lessons learned from a connection leak in production

How to test for connection leaks

How to connect your docker container to a service on the parent host