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
There’s a common model people seem to believe in implicitly, known as the Tuckman model, named for psychologist Bruce Tuckman, who published the idea in 1965. The idea is that all teams go through several distinct stages: Forming, Storming, Norming, and Performing. You can probably guess what those stages are like based on their names. The model has been a mainstay of agile coaches for many years.
But I’ve had doubts about the Tuckman model for a long time. My personal experience has been that once people get used to working in a collaborative way, they can move to new teams without any friction.
Continue reading Whither Tuckman?
The Code Freeze 2021 virtual conference culminated in a two-hour mob programming (a.k.a. ensemble work or samman) workshop. Seventy-four participants worked in 17 groups, each facilitated by an experienced mobber. Facilitators included such luminaries as Woody Zuill, Llewellyn Falco, and Jeff Langr, among lesser lights.
Continue reading Code Freeze 2021: Mob Programming Workshop
The most popular metric for agile software development teams, by quite a margin, seems to be velocity. Yet, experienced agilists don’t find velocity particularly useful. Even some of the authors of the Agile Manifesto who played a part in defining velocity, as well as story points and planning poker, have moved on. But today, as large organizations undertake major initiatives to “transform” into agile organizations, there is a strong emphasis on velocity as a key metric.
Despite the advice of leading agile consultants and coaches, and books like Doc Norton’s Escape Velocity and my own Software Development Metrics, corporate leaders stress the importance of velocity in their transformation programs, and require their software development teams to track and report it.
Continue reading Terminal Velocity for Agile Teams
Many of us who try to help others learn and use good software development practices have made the case that if only a person would try a recommended technique and get used to it, eventually they would see improvements in code quality and a reduction in delivery time, and probably easier maintenance of the code base, too.
It’s generally true that when we begin to learn a new skill we work more slowly than we will after we’ve learned to apply the skill effectively. This seems to make many people hesitant to try anything different than their current practices. The idea of slowing down temporarily in order to improve “later” is hard to accept. People have difficulty accepting any short-term cost in order to achieve long-term gain.
But what does it mean…eventually or later or after a while? When is “eventually?” How much “later?” How long is “a while?” People are afraid the temporary slow-down during their initial learning curve will have too much impact on delivery time, or will take too long to overcome.
Continue reading Pain today, gain tomorrow?
I began my career working on IBM mainframes in 1977, moved away from that platform gradually from about 1987 to about 1994, and have recently begun to return “home” again (also gradually). I have been heavily influenced by some of the advancements in software development in the world of Java, C#, and similar languages.
As I work more closely with mainframers and with vendors and open source developers who focus on the IBM mainframe platform, I’m confronted with cultural differences between those who work on mainframes and those who work, as mainframers put it, in the “distributed” world (that is, everything that isn’t a mainframe).
Continue reading Cultural Divide and Implications for Tools and Practices: Mainframe vs. Distributed