Home > Blogs > DIY Doesn't Cut the Mustard

DIY Doesn't Cut the Mustard

As our team size grows, we compartmentalize ourselves into more and more specific roles: project manager, scrum master, developer, tester, a wide range of others. With this often comes the assumption that each role has the responsibility to produce specific products or artifacts: a project schedule, a specification, the product of our roles. Problems arise when we take that assumption to mean that we are the sole proprietors of the products of our roles: that we have the responsibility of doing it ourselves.

The experience of producing one element of a larger system can be harrowing, extremely rewarding, or anywhere in between. When we are tasked with getting something done, especially if we work in the context of strong information regarding what the content should be, and effective guidance in the form of a template or example from a previous project, it can appear deceptively easy to get the job done. Work breakdown structures help us remember everything we need to consider when building out a project schedule, document templates will give us an outline that allows us to simply fill in the blanks, even the defined structure of a daily scrum meeting gives us guidance on who needs to participate (everyone) and what they need to cover.

Unfortunately, when we are doing these things on our own, it is too easy to fall into the trap of following the letter rather than the intent. For collaborative events such as scrums, we can still think of this as a DIY activity if it is only the scrum master that considers whether the intent of the collaboration was achieved. With one person thinking about whether we are done, it is easy to satisfy our own preconceived notions of what is done. We will often be working to some deadline, and the task often becomes an exercise of making sure that all the fields are filled in with something within the time constrants, then polishing if you are lucky enough to have any time remaining (and there isn’t any other pressing tasks to deal with).

That’s great, and we can often check off the completion box on that task, but are we really done? As others are in the same boat, review is often superficial, and deep issues only arise much further downstream. For most tasks on a project, if you were to hand them out to be completed independently by different people, you would easily find that everyone would complete the task, believe they had done a good job, but provide wildly different solutions for the task. A great example of this is the production of a vision statement for a project: a simple expression of who the key client is and what problem is being solved, along with an identification of the key competitor and the primary differentiation. Ask each person on the team to complete this independently, and it is guaranteed that you will get very different results, each one being complete. This is a problem.

If done in a collaborative fashion, the dynamics are completely reversed. The differences of perspective are exposed early, highlighting the need for further discussion and clarification. The team works together to come to a common understanding, rather than the team inheriting one viewpoint and having to live with it, as occurs most of the time. Done this way, these discussions occur with the right people at the table, at the right time in the project. Compare this to the late-in-the-project discovery that there was no alignment in vision.

As we split into more and more detailed roles on a project then, we need to think of the things we each need to get done as things we are responsible for ensuring they are done, rather than things we need to do ourselves. In this way, we make sure that different perspectives are appropriately balanced. With broader participation, everyone has a stake in the production of the artifact, and with that stake comes a stronger feeling of ownership: it becomes 'our plan' rather than 'his plan', or 'our tests' rather than 'his tests'. Big difference. It helps break down the silos between departments, the handing over the wall of artifacts between different roles, the carrying down from the mount of the stone tablets that drive our work.

The whole group becomes responsible for a successful project. Even if one person has the lead in ensuring something gets done, that person should never be alone in the activity. Nobody likes to be told what they should be doing, or what they have to do. It is far better to be part of the decision making process, to have the opportunity to see what is needed and step up and volunteer for the task. The stake and ownership itself will tend to provide success far more often. The counter-argument of not having enough time to collaborate on these things just doesn’t fly. I’m not suggesting that everyone participate together for every component of every task, but anyone affected by a decision should be involved in the decision-making process. If we do things on our own, the collisions downstream because we don’t involve others will cost us far more in the long run, even if we don’t account for these costs against the original activity.

Regardless of your role, don’t get caught in the trap of thinking that you are solely responsible for the products of that role. A better way of looking at things is that you are being tasked with making sure that the decisions your role is in charge of actually get done, but get done and agreed upon taking everyone’s perspectives into account. The perspectives of others can only be clearly understood if they participate: don’t do it yourself.

Become an InformIT Member

Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.