7 posts tagged with "agile"

In reaction to all of the "agile is dead" articles, I am cleaning up old posts about Agile, re-reading them, contemplating lessons learned but forgotten, and asking myself if some practices have outlived their usefulness. That is the spirit of agility: the interplay of action and reflection.

"Agile" is not a silver bullet for improving software productivity, reliability, and simplicity. But "Agile" continues to give us tools that can foster improved software engineering.

The Agile Manifesto was a distillation of certain trends that the authors had noticed in their successful projects. On balance, they ring true to my twenty-five year career in software.

It did not offer guarantees and it did not offer to solve world hunger. Through prescriptive frameworks such as Extreme Programming and Scrum, and common practices such as development of story cards and short cycles (aka sprints), the Agile "revolution" broke us free from the confines of gigantic requirements and design documents that were always at least slightly wrong, and frequently very difficult to change. It helped us embrace the uncertainty of software development, empowering us to find our way out of that wrongness more quickly and productively.

Like many, when I first encountered the term "agile software development," I thought it was an excuse for a cowboy culture: low planning, low documentation, run as fast as you can and assume that each person's brilliance will take care of everything. Since it came up in the context of a very large client asking us about our methodology ("what's a software development methodology?" I asked myself), I thought I should dig into a little more. Integrating Agile Development in the Real World, by Peter Schuh, quickly showed me it is not that simple. Agile development is, in fact, all about fostering a systematic, right-sized, just-in-time development process. For me, being "agile" means embracing change instead of being locked into preconceived notions (requirements). But don't throw everything out the window either.

A co-worker overheard the comment that "agile [software development] is not always a good fit for introverts," or something along those lines, while listening to a webinar on agile testing. On the surface, it is hard to deny that claim. Right there in the Agile Manifesto we have two obvious yellow or even red flags:

• Individuals and interactions, and
• Customer collaboration

Now jumping over to the Principles, we find two more orange flags:

• Business people and developers must work together daily throughout the project.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Sometimes you need to go back to the basics - including basic technology. In this case, I mean sticky notes. Yes, they are a remarkable form of technology. I like doing everything the digital way. I abhor using paper when not necessary, because of the waste factor. Although I love the idea of note cards for user story development, I've been thankful that they are impractical for my development team. But, I think it is time to heed good advice.

Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce

I did not realize how much I still have to learn about writing good object-oriented (OO) code, and about hewing to a tight test driven development (TDD) methodology, before I read Growing Object-Oriented Software, Guided By Tests. My education in OO and unit testing has been largely theoretical, with no time spent directly learning from experienced OO programmers; my best mentor was a COBOL coder. Books like Design Patterns: Elements of Reusable Object-Oriented Software ("Gang of Four"), Patterns of Enterprise Application Architecture, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Xunit Test Patterns: Refactoring Test Code, and others are wonderful but have few detailed real-world business-case examples.

In the chapter titled "Plan the System for Change," Dr. Brooks again lays out the foundations for Agile software development. His was an era of dumb-terminals and highly scheduled availability. And yet, here he is saying, "plan to throw one away; you will, anyhow." When RAM wasn't cheap, and good programmers even more rare than today, how does a project manager or architect justify throwing out the first design on purpose? By recognizing that "[t]he only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers."

A friend just wrote to me, asking about agile. He's been seeing software job posting with the vague request/promise of "agile" in them, wondering what the big deal is. Initial reaction: if no specific methodology or agile principle is cited, then at worst they are glomming on to pop culture, at best they want to make sure you can

1. handle changing requirements,
2. deliver prototypes and/or working code frequently,
3. take an iterative approach to documentation, coding, and testing.

"Being agile" means both that you aren't going to freak out at the lack of a locked-down, step-by-step waterfall process, and that you aren't going to go cowboy and give the client a product at the last minute, with no conversations or demonstrations between the initial requirements "gathering" and delivery.