Browsed by
Category: Agile

Agile across the Generations

Agile across the Generations

Comments 2 comments

In a post last month I discussed the Agile method, and described an origin story for it. In my story, Agile was invented by a new generation of software developers for a new generation of software – the software being written in the fast-paced world of the networked personal computer. It started when an “Agile Manifesto” was declared in 2001, at the height of the dot-com boom, after the software world had experienced a couple of decades of rapid growth amidst a profound shift in work patterns. A rising young generation (my own, Generation X) moved freely from job to job, eschewing loyalty to the company in favor of careers as “perma-temps.” Some system was needed to manage the frenetic chaos of this new working environment, and that’s where Agile came in.

This surely is a simplification and possibly off the mark. After all, innovation in workflow management precedes the Agile manifesto by generations. It has been a part of the evolution of the modern corporation for more than a century, going back at least to Taylorism and scientific management. Agile fits in with other conceptualizations of “lightweight” or “lean” approaches to project management, meant to avoid bogging everyone down with process and minutiae, and with earlier iterative development methodologies. These came about long before my generation was in the workforce.

My origin story came about because the Agile methodology strikingly fits the peer personalities of the generations who invented it – Baby Boomers and Generation X. If you look up the signatories of the Agile Manifesto, almost all of them are from those two generations, which constituted the bulk of workforce at the time (Millennials were only just graduating from high school). These are both generations know for individualism, for focus on the self and the personal, and for short-term thinking. It makes sense that they would embrace a work methodology that emphasizes individuals over process, and adaptability over planning.

The very name “Agile” evokes the ideas of speed and flexibility, qualities which align with my generation’s reputation. Also aligning with Generation X is Agile’s way of defining success as developing software that works, not necessarily software that is perfectly crafted or meticulously documented. “Git-R-Done!” or “Just Do It!” as a Gen Xer might say. Or how about the Agile sub-type known as “extreme programming,” a hyper-focused iterative approach with very short cycles? What could be more Gen X than that?

My point is that this methodology was primed for the workforce of the time – a workforce consisting of young adult Gen Xers, managed by middle-aged Boomers. The hyper-focused individualists were doing the work while the visionaries were directing them. Agile, in theory, was a mindset, a whole philosophy of managing work in a fast-paced world. So long as everyone was not worried too much about following a fixed process or plan, but instead was adaptable and constantly communicating, much could be accomplished.

Contrast this with Six Sigma, a methodology that came from the Silent Generation when they were the middle-aged managers of young adult Boomers. This faultfinding approach, which uses statistical methods to eliminate defects in processes, suits the Silent Generation’s reputation for fine-tuning expertise, as well as the Boomer Generation’s reputation for perfectionism.

Now what about Agile in the workforce today? It’s been over twenty years since the manifesto was published, and now it’s Gen Xers who are the middle-aged managers and Millennials who are the young adult workers. Does the Agile methodology suit a generation known more for hivemind thinking than for focused individualism? I think it does, though maybe not in exactly the way it was originally envisioned.

I have been using Agile at work for the better part of the last ten years, at all three of my most recent software development jobs. In my experience, the ideal of the “Agile mindset” doesn’t really stick. It’s fine to have an overall philosophy of work, but actually getting people to adopt a specific mindset requires coaching and attention, not simply declaring a vision. What does stick easily about Agile is the framework of dividing the work into short sprints and keeping the team aligned, using regular meetings (such as a daily scrum or stand up) and a system for tracking the work (such as user stories on a storyboard).

I think the structure provided by this framework is a good fit for the peer personality of the Millennial generation, who do best in an orderly work environment with clearly set expectations. They like to be given a well-defined task and rewarded for accomplishing it. A little praise and gratitude will do. They even get FOMO when they don’t have a specific assignment, which is understandable as it might be a sign that their position isn’t needed any longer.

Even as Agile methodology supplies structure, the short duration of the sprints and the iterative workflow continue to provide the benefits of flexibility as project priorities and personnel shift about. A plethora of practices and sub-methods has evolved out of the original idea, giving Gen X and Elder Millennial managers plenty of ways to tinker with the methodology to find the best fit for their teams.

It’s worth noting that there are limitations that come about when you have structure. If everything has to be tracked, work might not get done if no one remembers to track it. If expectations are clear, there might not be much motivation to go beyond expectations. A well ordered framework for defining and assigning work might be easy to navigate, but it can also foster complacency. No one is likely to go above and beyond, if there doesn’t seem to be any particular reward for doing so, and if doing so risks ruffling feathers by disrupting the expected workflow.

Continuing the story of Agile, it might be that what started as a methodology for producing results in a fast-paced environment has evolved into a methodology for governing work in an orderly manner, such that everyone can function in a well-defined role. That’s what my experience shows. Agile might not be as versatile in practice as it was originally envisioned to be, but it’s still a useful tool for keeping teams aligned and productive.

I do sometimes hear an old Gen Xer on a team complain that “we’re not practicing true Agile,” but I just think, “so what?” We’re getting stuff done (hopefully), and keeping tabs on it. That’s enough.

As far as I can tell, Agile, at least in name, is here to stay. The concept is entrenched in the Information Technology workplace, and will certainly outlast my career, which has not much more than a decade to go. Ten years from now the generation that comes after Millennials, the Homeland Generation, will fill the twenty-something age bracket and constitute the workforce’s youngest cohorts. I wonder what further evolution of the Agile method might come along with them.

How We Got Agile: An Origin Story

How We Got Agile: An Origin Story

Comments 3 comments
My old copy of “the mythical man-month”

When I was a young man, a college student in the Computer Science program at Virginia Polytechnic Institute, we were assigned a book to read. It was called The Mythical Man-Month, by Frederick P. Brooks, Jr., and I still have my copy from the 1980s. The point of the book, which you might be able to glean from the title, is that you can’t simply measure work effort in “man-months,” on a scale such that you could conceivably get more work done by adding more people to a project. As an example, you couldn’t say that a project has a work effort of 120 man-months, meaning that with 10 men it will take 12 months to finish, and therefore with 20 men it will be done in 6 months.

If you had 10 men working on this hypothetical project, and added 10 more, you would not find that it completed 6 months sooner. It would, in fact, take longer than 12 months. The problem is, as you add more men (people) to a project, you need time to get new hires ramped up to where they understand the project well enough to be productive. You also multiply the lines of communication, which generates additional overhead keeping everyone in sync on specific information needed to make interacting components work together. In engineering, these pieces of information are called “specifications,” and they have to be tracked somehow. If you add more people to a technical project, you add more tracking effort. These complications are summarized in Brook’s law: “Adding manpower to a late software project makes it later”.

As a software engineer in the early 21st century, it fascinates me to read the author’s description of how specifications were tracked on the project he worked on – the IBM System/360 – in the 1950s and 60s. They had huge manuals kept in binders, and as changes were made, the responsible engineers would have to go in to the binders and update the appropriate pages – that is, take out the old pages and insert the new ones with the changed specs. This manual was the Bible of the system, and keeping it up to date was abolutely vital to the success of the project.

Modern day software engineers like me are not used to such meticulously maintained documentation. We consider ourselves lucky if there is any documentation at all for the software on which we are working. You’d think it would be easier, now that everything can be done online, but projects move too fast and the people working on them move around too much. No one is necessarily going to stay on top of documentation, and so long as software works as expected, that’s fine. It’s when it doesn’t work that you run into trouble.

Because personnel move around so frequently in the modern workforce, there is rarely anyone working on a software program who was there when it was originally programmed. But programmers still need to maintain it. Sometimes we are given requirements to modify existing software that has no documentation, with no one around who knows anything about it, and the only way to achieve that goal is through “reverse engineering.” This means poring over old code and documenting it from scratch, which is very time consuming. This underscores the point about the man-month: you can’t just insert a person into a project and expect them to get as much done in a given amount of time as a previous person on the project did. Certainly not if they are going to be reverse engineering the previous person’s work.

Since the start of the personal computing era and the long economic boom of the late 20th and early 21st centuries, computer software has been advancing at a faster pace than it did when Frederick P. Brooks worked as an engineer at IBM. The workforce has changed as well, with employees typically job hopping every few years, and often working as contractors through agencies rather than directly for the client that owns the software they are developing. So how do the software engineers of my generation handle project management in such a chaotic work environment?

The answer is “Agile” methodology, which came about around the start of this century. Agile is a lean or lightweight software development method that emphasizes individuals collaborating over plans and processes, and defines good software as software that works, not necessarily software that is well documented. At least, that’s the declaration in a famous “Manifesto for Agile Software Development” that was published in 2001.

The idea is that “Agile” is a mindset where you are focused as a team on communication and collaboration, continuous improvement, and responsiveness to change. In practice, it means breaking up the project work into short iterations called “sprints,” which typically last two weeks. Everyone’s tasks for the sprint are things that shouldn’t take more than a couple of weeks to finish. So right there the idea of a “man-month” is out; no one would work on one thing for a whole month!

Breaking the project work into chunks like this makes it easier to show progress, and to evaluate how effective the team is from sprint to sprint, and change processes and workflows as needed. It also makes it easier to accomodate personnel shifting around from project to project. It’s a way of coping with today’s volatile workplace, which makes long term planning harder to achieve. A whole panoply of “frameworks” and “ceremonies” has developed around the original concept since it was first elucidated.

If you are in a white collar profession (not even necessarily Information Technology) you might have experience with Agile-related frameworks in your career. I was first exposed to Agile in the late 2000s, and have been at positions where it is used comprehensively since 2018. Every company does it a little differently, but I have always found it to be a useful way to structure project work.

The way I see it, Agile came about because a new generation of software engineers needed to adapt to a faster pace of work than what the generation of Frederick P. Brooks experienced in their careers. They needed to find their own solution to the problem of how to get people to work effectively when they are added, out of the blue, to a new project. If you look at the signatories of the 2001 Agile Manifesto, you will see that they are almost entirely Baby Boomers and Gen Xers. Today’s Millennials and Gen Zers in the IT workforce have possibly never worked on a project that wasn’t using Agile.

I’ll have more to say about the different generations and Agile in a future post.