Session Summary [DevOps Camp compact 2017]

Introduction

At the BarCamp “DevOps Camp compact 2017” last weekend, I moderated a discussion round based on the question

“What prevents you from doing software development effectively?”

The original reason for this question was that I wanted to know if I’m trying to solve existing problems. I urgently had to find out if it’s just me that sees all those problems in companies or if those problems exist in other companies, too.

The “survey”

I also spontaneously decided to conduct a survey on this topic based on the questions from clean-coding-cosmos.de. They gathered various problems from various developers, summarized them, worked out the causes and conducted surveys as well.

So, the results from my small (absolutely non-representative) survey with 21 participants (most of them developers and operators, who guessed that?) is this one:

Cause	Percentage
Political decisions	38,1%
Low or missing test coverage	33,3%
Missing, unclear, different quality perceptions	33,3%
Pressure of time, many workarounds, “Quick & Dirty” mentality	33,3%
Human weaknesses of team members (including myself)	28,6%
Lack of understanding of software development in management	23,8%
Project management sets wrong priorities	19,0%
Unclear requirements	19,0%
Incomprehensible code	14,3%
Lack of role clarification	14,3%
Lack of training	14,3%
Management pressure (overtime, “develop faster!”)	14,3%
Rigid organizational structures	14,3%
Too often & quickly changing requirements	14,3%
Unnecessary meetings & discussions	14,3%
Inadequate coordination and cooperation with the domain experts	9,5%
Insufficient communication in the team	9,5%
Insufficient coordination and cooperation with requirements management	9,5%
No or weak development process; lack of processes dicipline	9,5%
Customers that need too long to approve features for release	4,8%
Insufficient coordination and collaboration between the developer and operations	4,8%
Insufficient training of employees	4,8%
Motivation deficiencies: e.g. little feedback, criticism, praise	4,8%
Nothing	4,8%
Poor team spirit	4,8%
Technologies inefficient / ineffective	4,8%
Time	4,8%
Too few developers	4,8%

I was very glad that the first one was political decisions because this is exactly the problem that I’m primarily focusing on with my take on “automated, data-centric and reproducible analysis of software data” 🙂 !

In the following, I tried to summarize the main discussion points and added some personal notes.

Discussions

We only had the time to speak about the most urgent problems and started with political decisions. This topic is a broad one. Some even saw statements like “We did it that way for years now” as political decisions (aka “not looking at the real facts” or “being rational”). One participant successfully broke through such a killer phrase by researching alternative solutions in his free time. With a possible solution at hand, he went to his product managers and demanded further, (paid) working days to implement a first prototype. After success, he was able to get two more days to roll out the solutions as actual improvement.

I like the incremental approach where you invest some time upfront to get a reasonable idea, propose that as a possible solution, gain some budget for prototyping and get additional days for implementing a sustainable solution.

Spending free time as the ultimate solution was not accepted by every participant. Others proposed “slack time” as an alternative, where some working time (say 15%) could be spent for pure improvement work with the aim to make software developers more efficient. They gathered very good experiences with this model albeit it was quite some work to convince management for approval of slack time. In this context, another participant asked a very interesting the question. He asked if we would mainly “work forwards” (work that is directed towards the future) or “work backward” (work that fixes just deficiencies/problems made in the past). Most of us just did work backward, but the developers that had slack time said, they would work forwards at least during their slack time. Interesting!

Others fought political decisions by objectively comparing different solutions. One participant told us, that his management was very focused on products of a specific vendor (that also organized golf tournaments or “road shows” for customers). It was very hard to convince management by reasoning or even numbers. But the developer was able to organize an arrangement where other software companies could demonstrate how they would solve the existing business problem. Each of the other companies did a better job than the specific company. So management was convinced that choosing another company was best.

I find that developers should hold an opinion longer than expected from management. Especially in these times, management can’t afford to lose valuable developers just for some additional shots (on golf courses or “road shows”).

Another point of intense discussions was the Missing, unclear, different quality perceptions problem that was interpreted mostly as a different understanding of the term “quality” between developers and domain experts/management. Together with Lack of understanding of software development in management, we found that management could be underestimating the impact of their visions on non-functional requirements (especially the internal software quality). Management is in most cases too buzzword-driven without having an actual need for it. More problems arise if there are technical people that just say “yes” to everything (e. g. to go up the ladder or because of the lack of knowledge). They seem to be acting in the name of developers but are actually acting completely irresponsible instead.

We thought that there have to be developers that can understand the viewpoints of management as well as the concerns of developers.

But from my point of view, all this political theater leads to the problem that skillful developers don’t want those jobs.

Additionally, one participant said that they would currently work on minimizing the lack of understanding by building feature teams aka cross-functional teams. With this approach, you aren’t focused on the organizational hierarchy but on the success of the current project/feature regardless of your role in the organization. This could lead to a feeling of common responsibility for the whole company.

I think this could work as well, but it needs instruments for radical transparency to avoid cannibalism or blame games between the feature teams. If you don’t have that, you are just pivoting the original problem.

Finally, one person gave the answer “Nothing”! I immediately had to find out who this person was and where he or she works. I found him: A young software developer that works in a company that provides a Software as a Service compliance for generating automated marketing content. He was responsible for the overall operation of the application in a developer team with around ten people (if I remember correctly). The team is completely self-organized, works with Kanban and every developer takes the tasks where he thinks that he could do it best. One thing that impressed me by far was that the whole developer team regularly rejects tasks that are out of their main goal (e. g. creating a website for marketing). This shows that no team member gets weak in accepting work that needs their special expertise but it’s just a programming-related task. They are also in kind of constant slack time because they know if the work forwards, they will be successful.

I’m really happy that some software companies already got the message 🙂 !

Summary

Here are my key takeaways:

• My introductory slides were superfluous.

• The problems I’ve encountered so far exist in other companies as well.

• Dedicated hours for improvement work (aka slack time) is a great instrument to reduce most of the problems.

• Say “No!” more often!

• The topic “problems” is so broad that you could easily fill a complete BarCamp with this!

• BarCamps on weekends where employees attend in their free time are great (leaves out all the 9-to-5-workers 🙂 ).

• Google Forms is a PITA when it comes to evaluation…

 

Overall, I found the session very inspiring and I’m thinking about repeating this format at other BarCamps as well.

Thanks to all participants and the great discussions!

 

PS: You can look up all the other great stuff that happend at DevOps Camp compact 2017 on Twitter.

PPS: Did I miss something important or are there questions left? We can continue the discussion here if you like 🙂 !

Image source