I want to talk about the frustration that everyone involved with designing and building technology based solutions will have encountered at some stage. It goes someway to explain why Hubscope was conceived in the first place; as a tool for helping to solve this particular problem.
I don’t mean a lack of collaboration, this problem is now widely understood and agile is well on the way to resolving. I’m referring to a lack of any shared comprehension for multi-disciplinary teams.
Test this by asking everyone in your team to draw a one-page picture of your current project and to highlight the specific piece they are currently working on. Then compare them and try to join them together. Unless your team works for NASA I suspect things won’t join up so well and it may look like there are several disjointed projects underway.
Part of the problem is that people use different terminology. But the main challenge is that we have no way of collectively expressing the interdependence we share with each other. I like the word ‘interdependence’ – it’s common enough not to be owned by any one role yet not so common as to be over used. At the time of writing Wikipedia sums it up as “In relationships, interdependence is the degree to which members of the group are mutually dependent on the others. This concept differs from a dependent relationship, where some members are dependent and some are not.” The delivery of a successful technology project is not determined by how well joined up the technology is but on how well the team specifying, designing, building and delivering the technology are joined up in their thinking.
If it isn’t easy for people to convey how what they’re doing fits in with the rest of the project in a free-style manner, then it’s no wonder that it’s hard to keep the end game in mind when team members are doing their jobs and communicating across the different roles.
Hubscope is all about providing a way for any IT delivery project to understand and expose its interdependencies. Thus reducing risk and increasing the joined up quality of the end result.
I don’t think we can talk about technology usage without mentioning a methodology which provides guidance of how to use it. I’d like to be able to say that using Hubscope is so intuitive than no guidance at all is required. While this might be the case for people just viewing information, it certainly is not the case for people who want to contribute, which must obviously happen first. I would also argue that everyone on the project needs to be strongly encouraged to contribute at some point, even if it is just to correct someone else’s misunderstanding or mistake.
I’m calling this methodology “Team Interdependency Resolution”. I did consider calling it “Team Interdependency Negotiation” but this implies a conflict of opinion in some way which may be the case but on the whole it is resolution we are looking for as there is common ground galore on projects once you start joining the dots.
Here’s a scenario that illustrates an interview approach that can be used to identify and resolve interdependencies:
- Business Analyst Interviewing Business Owner and a senior user of the new system: “Who are the major stakeholders and what do they want this project to achieve?” This provides a stakeholder and requirement perspective.
- Architect interviewing Business Analyst: “What service capabilities do we need to deliver to meet these needs?” This provides a services perspective, elaborates on the requirements and identifies the interdependencies.
- Technical team interview Architect: “What technology should we build that will provide the identified services? How can we boil down the overall solution to as simple a representation as possible, so that everyone can understand what we are building and why? This provides the technology perspective and traces through the services perspective to show how each of the requirements is being met.
- Everyone interviewing everyone: “What key interdependencies does the project need to focus on to ensure any risks around delivering the required services are minimised?” This can occur using any of the above perspectives or using an end to end view of the whole project.
By working towards an end to end view, normally starting with the stakeholder requirements, everyone can get involved and see the evolution of the single inter-connected view. By sharing and evolving this end to end perspective throughout the project any discussions and stand-ups will become much more informed and inclusive.
‘One Project, One Objective, Different Perspectives,’ summarises our approach as we seek to remind everyone that they are all working to the same project objective but need to understand how their perspective on the project relates to, supports and depends upon others. Hubscope lets everyone in the team contribute their unique insights and combines them into a common objective that can be viewed from many different perspectives.