DevOps Does Not Promote Collaboration
After a couple of decades of coding and a few different software methodologies later I’ve come to the conclusion that any software methodology will fail without collaboration. Collaboration is touted as a leadership thing. That is starts at the top. But in reality it is not. It is solely how people treat each other on a team.
The software methodology that took hold and turned my division into a well-hone, release-producing machine was born in a small team working on a project. No managers, no methodologies, just two groups, development and QA, that wanted to try something different to make the release process smoother. Collaboration is not easy to achieve, (I can certainly attest to that) but once achieved any organization will reap the benefits, including those promoted by the latest methodology craze, DevOps. So how do you get there?
I Hear You, You Hear Me
It starts at the beginning, when, in the case of software development, product management decides it’s time for a product release. Nothing screams stress (or failure) like biting off more than you can chew. Knowing how much work to include in a project is always a challenge, especially when there is a target window for its release. The scope must be a consensus between product marketing, project managers and senior project technical staff.
Consensus requires understanding. Each group must be willing to understand the point of view of the other without which the team cannot fully understand the scope of work on the table. Consensus also requires trust that each group is painting a truthful picture of their portion of the scope of work. There can be no hidden agendas during these discussions. Hidden agendas will reveal themselves during the project and will be responsible for project delays, or worse, its failure.
One of the biggest battles during these meetings is product features (something the customer can see and therefore willing to pay for) vs technical debt (more often than not, something the customer cannot see and thus reluctant to pay for). Today’s rapidly changing technologies make it increasingly harder to avoid addressing technical debt. These improvements are generally for the benefit of internal operations yielding reduced costs, improved performance or security and increased productivity. When all parties put their cards on the table and understand what those cards represent, it becomes clearer where efforts must be put in order to not just achieve, but maintain a high performing (customer features), highly productive (technical debt) organization.
No One is Perfect
You’ve agreed on the scope of work, now you have to figure out when you can deliver it.
It’s no secret that product marketing, sales and the C-suite want your project completed and deployed as soon as possible, which loosely translates into yesterday. We have all felt that pressure. It is real and constant. We also know that once you commit to a finish date, the expectations are set. Marketing, sales and customers will hold you to that date. Like it’s written in stone. There’s a lot riding on these numbers.
Committing to an estimate is stressful event. Once committed many feel their very reputation is on the line. No one wants to get it wrong. Worse, no one feels they can afford to get it wrong. Underestimate your time and you face decreased quality because you rush to completion or miss deadlines all together. Overestimate and you face a double whammy. If you get your work done early people view you as an obstacle in any project because you sandbag your estimates. Or, if people don’t see you working nose-to-the-grindstone you are lazy. Estimating is viewed as a no-win situation.
To get past this everyone must first accept that estimates are just that, estimates. We don’t believe humans can predict the future with 100% accuracy so why do we think estimates should be written in stone? Estimating should be viewed as a skill. One that should be developed so that we can improve our accuracy (but not to the point of expecting perfection).
Some feel estimates are just a number you pull from your gut when in fact, that is just a place to start. Enlist help from people who can bring an objective or experienced eye – managers who can offer data from past projects or senior members who may have experience doing similar work.
When my development shop first started using our own home-grown methodology, I was surprised to find out that our manager adjusted our estimates when making the project timeline. I was also surprised to find out, he wasn’t wrong in doing so. His decisions to adjust estimates were based on observations from past development projects. Sharing his observations with us made all the difference as we all improved our estimating skills to repeatedly delivered project after project, (mostly) on-time and (mostly) on-budget.
Armor Not Required
Nothing will tear a team apart faster than team members having to don a suit of armor before any meeting. This is especially true during design meetings, specification meetings, review meetings and status meetings…yep, that’s one big chunk of the project.
It’s hard to do, but team members must practice a solution-oriented focus not a person-oriented focus so that everyone can leave their suit of armor at home. It is easier to throw ideas on the table when you know what follows will be an objective evaluation of the idea and its value to the project and not a personal attack on all the many ways you erred in your thinking.
I was in a design meeting where we have had an intense, knock-down, drag-out fight over the design for a new feature. Though we spoke directly (and sometimes loudly) to each other, the discussion was always focused on what was best for the product and its long-term health. Never personal. The design was selected by majority vote. Everyone supported the final decision. The meeting was adjourned. We all went to lunch. We spent the time talking about how fun and invigorating that meeting was.
Review and status meetings are especially tricky. It is extremely easy for these meetings to quickly turn to finger pointing and personal attacks (i.e. “You’re behind that’s why I can’t do my job”, “Your API has no business accessing that sensitive information”). We’ve all fallen behind. We’ve all had situations when we just didn’t understand. We’ve all gone down the wrong path and had to reverse direction. We all want nothing more than correct it and move on.
Solution-oriented thinking puts the focus on fixing the problem at hand and moving the group forward together rather than causing individuals to duck and cover, or groups to rally their wagons, in defense.
We Have No Secrets
It’s a myth that hoarding knowledge makes you invaluable. What makes you invaluable is your willingness to share everything you know, help where you can and admit when you don’t know. That kind of openness will lead others to seek you out. That kind of openness leads to a free flow of information. If you withhold information, no one will talk to you. What would be the point? They will get no information. They will go elsewhere and find the information they need. Then what value is the one that withheld that information in the first place?
Sometimes people think that without formal lines of communication in place, valuable information will be lost, but the fact is this kind of free flow of information is self-governing. Those involved will weigh the importance of the information to determine how it is exchanged and with who - talk over coffee, over email or in a meeting – and if necessary, preserved. And because we have no secrets, everyone on the team has access to the preserved information.
I have been involved in countless discussions that initiated during some phase of a project by an individual who found something in the course of their work. Some issues were resolved quickly in talks or via an email exchange with the affected parties. Others discussions started with an email exchange, but were escalated by the group to a meeting. The issue being too complex or had too many potential solutions for an email exchange. Some resolved issues only required an email to disseminate the resolution information. Others needed a full-scale project review because the issue impacted the project timeline. What is important to note is that none of these exchanges were initiated by management. They all started in the trenches, by individuals working as a team to simply absorb the distraction and continue forward.
It’s Not Big Brother But it is Your Team
In this type of collaborative environment there really are no walls. Everyone really has a view of everyone else’s work. This does not mean that Big Brother is watching you, waiting for you to make a mistake. It does however mean that you, as an individual, are held accountable for your work by your team just as you hold your teammates accountable for theirs. But accountable does not, and cannot, mean humiliated.
Think about it. Have you ever accidentally slipped and broken something that didn’t belong to you? If it happens at home with your family, you apologize. You replace or fix the broken item if you can and everyone moves on. If it happens in public, some will follow the family example. Others will berate you in public, accuse you of breaking the item on purpose and demand more than a replacement. Then there will be the lucky individual that captured the moment on video and posted you on social media as an example of what not to do.
You are expected to do your work. You are expected to get it right. But as I have said before, we have all fallen behind, we have all been confused, we have all made mistakes. You should expect to be held accountable. You should not expect to be humiliated.
I don’t disagree at all with development methodologies. They bring repeatable structure to any project. And management support of collaboration is important. Otherwise you get that talk from your manager about priorities after spending the day helping another group solve a configuration or upgrade problem that has them stopped in their tracks when you yourself have tasks to complete for an upcoming deadline.
I do, however, believe that collaboration is an entity on its own that can (and should) be fostered outside of any massive methodology effort. Once people understand how to collaborate, collaboration just happens. The benefits of collaboration are not just for the organization. Individuals benefit as well, maybe even more than the organization. For the individual collaboration eases stress, fosters friendships, promotes learning, and can even make work enjoyable.
