Effective software development, delivery, and support
Way back in October, 2022, Florin Pop tweeted this question:
He got 400 responses in 10 hours. Some were lighthearted: “I would use HTML.” Others went into some detail about a favorite webapp development stack. I came to the party late, but I thought it would be a fun thing to try.
If you understand how these things relate to software development work, then you require no training or coaching.
Handling stress and working with others requires self-awareness and emotional control. All the skills listed here also require self-awareness and emotional control.
It is widely agreed that software development teams are either improving mindfully, or they are deteriorating in their effectiveness. There is no steady state. To make improvement possible, team members must be open to learning new things and willing to question things they already know.
To achieve anything, you must focus on it. That means uninterrupted time to think and work. It means finishing one thing before starting another. It means not getting distracted. It means keeping your eyes on the goal and not on dwelling on the difficulties.
Overcoming challenges and meeting objectives requires persistence. Embracing change to improve our work requires persistence.
In almost all cases, software development work benefits from collaboration between two or more people. “The more you share, the more your bowl will be plentiful.” – James S.A. Corey, The Expanse.
Effective collaboration requires trust and the courage to be seen as vulnerable or imperfect.
Leadership doesn’t mean giving orders. It means giving credit, giving time, giving space, giving encouragement, giving opportunity, giving trust. The more you give, the more you get.
A steady, predictable, consistent, and sustainable pace of work helps ensure continuous flow, maximize delivery effectiveness, and minimize team stress.
The field of software is constantly changing. Software architecture, design patterns, programming paradigms, methods and schools of testing, of analysis, and other areas, design principles, development practices, automation, operations, and everything else is a moving target. To get started in this field, you need basic education/training in analysis, programming, and testing, and the non-technical skills listed above so that you will have the ability to keep yourself current with technical advances and to collaborate with and learn from your colleagues.
Without the basic training, you will have no foundation to build on. It would be like trying to run a foot race on top of loose ice floes on water. The general discussion of what skills are necessary tends to emphasize the non-technical side of things; don’t take that to mean there are short-cuts on the technical side. The reason for the emphasis is that the non-technical skills have been underappreciated in the past. On the other hand, don’t worry if you feel as if there’s too much to learn. Once you have the basics, you can build on that knowledge little by little.
Here’s a story.
A development team was thrashing as they attempted to use Scrum to help them build a new application. They had numerous defects, some of which escaped to production and others that were caught within each Sprint. Many defects they thought they had fixed popped up again in production.
Their stakeholders had high expectations, as the team’s velocity was high. After several Sprints, it became clear they were not going to deliver all the planned features by the defined deadline. The news came as a surprise to stakeholders.
I’ve noticed in many business meetings, and especially presentations, people use highly stilted, quasi-academic language. They may have useful things to say, and a pleasant, cultured voice to say them with, but the language leads me to wonder why people think they have to sound academic at work, and whether they would speak that way normally in any other context.
I mean, if they think it makes them sound smart at work, wouldn’t they want to sound smart all the time? Who wouldn’t, right?
Continue reading What if people always spoke the way they do at work?
There’s an odd situation in the software industry. Employers are adamant that they can’t find suitable talent to fill the technical jobs they have. Job candidates are adamant that they can’t find suitable work. It seems strange to me that both these things are true at the same time.
Many people have opinions and observations about this. Often, they cite academic studies, industry surveys, formal management models, psychology, and various other things that are confusing for a Bear of Very Little Brain like me. I wonder if we could go a long way toward solving this problem if we ajusted, just slightly, the way we think about what we’re aiming to accomplish, on the hiring side and on the job search side.
William van den Ende was trying to find a good balance for quotes included in blog posts, and his effort inspired me to try and assemble a blog post entirely out of other people’s quotes.
It’s a bad idea. Set your expectations accordingly. Here goes.
Continue reading Scrum in quotes
Recently, I tweeted that I had presented a virtual training class in which we used remote mob programming for the lab exercises, and at the end the participants said their main take-away was not the technical content, but rather the value of direct collaboration. Colleagues who already understand and appreciate the power of collaboration were excited to hear the story.
But what about people who do not already understand and appreciate the power of collaboration? What was unique about the situation that brought collaboration to the fore, above and beyond the technical skills that were ostensibly the subject of the class? How closely does that situation align with more-typical software development realities?
Premise 1: Self-discipline is the only meaningful form of discipline.
Premise 2: Simpler solutions are usually preferable to more-complicated solutions to the same problem.
Premise 3: Without self-discipline on the part of those using it, no process model or method or framework or tool of any kind provides the value its proponents believe it can provide.
Premise 4: A formal process that imposes strict rules tends to teach people to follow rules rather than to cultivate self-discipline.
Premise 5: The longer and more deeply a person invests in a given idea or habit, the more difficult it becomes for that person to let go of the idea or habit, or even to question it.
Premise 6: In the diffusion of any innovation, the main reason Innovators and Early Adopters achieve better results than Late Adopters and Laggards is the former are predisposed to try unfamiliar things and take risks, and not primarily because the particular innovation is intrinsically better than whatever it replaces (even if it happens to be a little better on the merits).
Premise 7: The factor that makes an innovation useful is that it comes at a time when it is needed, in a context where it is needed, and to people who are in a position to make use of it; not necessarily that the innovation itself is “best” in a general or permanent sense.
I was reminded of that old saying when I was struggling to use one of the internal software tools we’re required to use at my current client. In this case, it was one of several time-tracking systems.
It led me to think about the difference in quality between the software the client creates to support customers, and the software they create for internal use. It seems to be a consistent pattern at many companies. They pay a great deal of attention to quality for customer-facing information systems, but when it comes to systems for internal use, they just throw something together quickly, and often carelessly.
The old saying, “In the blacksmith’s house, a wooden knife,” applies to our line of work. The question then becomes, Why?
Looking back over who-knows-how-many “agile transformation” and “agile coaching” engagements, it occurs to me that five experiences stand out as especially positive.
When I ask myself why, two elements present themselves: First, (in three cases) the development team was physically collocated with the end users and collaborated directly with them daily; and second, (in the other two cases) the team and the organization did not “lock in” any rigid definition of “agile,” and actively explored ways to move beyond the usual Agile 101 level of practice.