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?
Continue reading An incentive to collaborate
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.
Continue reading Discipline
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?
Continue reading En casa del herrero, cuchillo de madera
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.
Continue reading The best agile environments I’ve seen
What’s a time-box?
When working with people who are new to “agile” development methods, particularly Scrum, I notice there seems to be a great deal of confusion about the concept of a time-box.
Time-boxes are baked into Scrum at multiple levels. The Sprint is a time-box, and all the standard Scrum events are time-boxed. Yet, many people who adopt Scrum pay little attention to this aspect of the process. They begin their events late and they extend the time of an event if they haven’t yet met the objectives.
I don’t speak for the inventors of Scrum, but my understanding of the time-box mechanism is that it has two key functions for a team and organization. When people don’t use time-boxes in a way that enables those functions, it suggests they don’t quite understand what the time-box is for.
Continue reading What’s a time-box?
Product-Aligned Software Teams
For a long time now, and starting in earnest in the early 1990s, people involved with software development and delivery have been shifting various aspects of the work to the “left,” if you visualize a software delivery pipeline that runs from left to right. What’s the endgame?
Continue reading Product-Aligned Software Teams
As a young computer programmer, I moved to Dallas, Texas, without ever having been there before, and with no idea what the place was like. There were three attractors for me: (1) Reputedly good prospects for a career in information technology, (2) no State income tax, and (3) good Mexican food. Those of you know know me IRL will be unsurprised by which of those was the strongest attractor for me. Indeed, as I rolled into town the first time, I was delighted to see a Mexican restaurant on nearly every corner.
Some years later, I was working with a guy who had just completed an introductory Six Sigma class and had started the journey toward Green Belt status. In other words, an Expert. As he listened to the almost-daily discussion about which Mexican restaurant we should go to, he had a brilliant idea. He would assess Mexican restaurants by the quality of their refried beans.
Continue reading The Refried Beans of Agile
With over a year of daily teleconferencing, and a strong likelihood we’ll continue to work remotely after the pandemic, I’ve noticed a few things that help or hinder understanding on conference calls and virtual meetings. These mainly pertain to audio.
Of course, we’re not trained broadcast journalists, and we didn’t ask for the pandemic to keep us working from home for so long. Nevertheless, there are some things we can keep in mind to help our colleagues understand us clearly on videoconference calls.
Continue reading Tips for Teleconferencing
Once “agile” methods had crossed the chasm, organizations in the Late Adopter and Laggard categories began to try and roll out “agile” across their enterprises, or at least across their IT departments.
To support deep-pocketed enterprises that wanted to scale “agile,” consultancies sprouted up offering “frameworks” that could be dropped into place to achieve agility. They are generally based on Scrum and/or Kanban principles, in a way that often lends itself to fun (provided you aren’t the one paying for them).
As the years passed, large enterprises made multiple attempts to implement agile frameworks. With each attempt, they are growing smarter about what will or will not work at scale. But these lessons are excruciatingly expensive.
Despite the general results, consultancies that specialize in scaling agile methods continue to promote the idea. New books have appeared that explain how to scale agile in large enterprises. I checked Amazon books briefly, and got 14 hits for relatively recent books on the subject. But is it even a “subject?”
It occurs to me the basic reason for most of the difficulty is that “agile” as such simply does not scale. If that’s the case, then how can larger enterprises gain the benefits of agility? I think there is a way. It boils down to applying “agile” tactically rather than strategically; except perhaps to say that the strategy is to apply “agile” tactically.
Continue reading Tactical Agile
Recently, there’s been a lot of news about growth in opportunities for work in the COBOL language, owing to a resurgence of the IBM mainframe platform both to support mission-critical applications in key industries and to take advantage of IBM Z cloud computing capabilities. While IBM Z accounts for the majority of existing COBOL applications, the language is relevant to other platforms, as well.
Historically – if I may use such a word for an industry less than a century old – the computing market has been segmented into more levels than just “micro” and “mainframe.” Mid-sized enterprises have long faced a dilemma: Use relatively inexpensive microcomputer equipment and systems that barely keep up with the company’s demand for computing power, or pay heavily for mainframe systems that have several times more capacity than the company will ever use.
To serve that market, a number of computer companies provided midrange computers.
Most of the media play centers on the big iron – IBM Z – but midrange systems are in the same position today with respect to legacy systems and virtualization, and with respect to the generation of people who have been supporting them going into retirement. Companies have significant investment in and dependency on legacy systems, and the old systems are being modernized and cloud-enabled.
Which programming language do you suppose people used to write most of their applications on midrange systems? You guessed it: COBOL.
Continue reading COBOL: Not only for mainframes