Agile Programming

On this blog, we spend a lot of time dissecting the details of agile project management, even arguing over fine shades of distinction. But in an InfoQ article titled “Agile’s ‘One Essential Ingredient,’” Mike Bria reports on Mark Schumann’s wide-angle view of agile. Considering the single most important ingredient to success with agile, Schumann suggests that, beyond particular engineering techniques or even a specific methodology, the one thing that enables agile’s benefits is a legitimate shift in mindset. Certainly, this is something that many agile practitioners have already rallied around: For agile management to succeed at an organization, its practitioners must fully understand and embrace the philosophical changes it entails. Simply changing job titles or going through the motions won’t cut the mustard.

But Schumann goes on to explain that this cultural buy-off not only needs to occur at the team-level, but among managers, as well. While the three attributes of great agile teams—“correction, imagination, and trust”—are essential for teams to succeed, he argues that it’s even more important that management exhibit these traits, as well. From there, Schumann whittles agile’s most essential ingredient to “humility,” writing:

“Trust means you have to give up Control. A lot of it.
Imagination means you will have less Certainty.
Correction means you have to acknowledge that you never had Perfection to begin with.

“…the organizations that do well with Agile software development – or any other kind of Agile work for that matter – are the ones that can cope with losing Control, Certainty, and the assurance of Perfection.”

At the heart of the matter, Schumann is describing a general attitude of openness, in which management does not necessarily presume to know the right answer or best course of action. Instead, they remain open to the possibility that someone closer to the problem (that is, a developer) might have more insight into how to solve it. This is in line with agile’s use of iterations to constantly assess how to best respond to emerging conditions. Success is not the result of a prescriptive process, but, rather, a process of remaining observant and critical in order to react to reality.

You can read Schumann’s thoughts in full here, but I’m curious to hear from you readers. Would you agree that humility and meaningful support of agile from management is the factor that makes or breaks agile success?

Posted: November 9th, 2009 under Agile Programming.
Comments: 1

Lean has been a popular topic on this site lately, so I wanted to direct readers to a free report that Forrester Research recently published to coincide with their annual Business Technology Forum. This year’s theme is “Lean: The New Business Technology Imperative,” which focuses on how Lean can help organizations reduce waste, create value for customers, and help them respond more nimbly to emerging conditions. Take a look at the free analyst report here.

Posted: October 15th, 2009 under Agile Programming.
Comments: none

Finally, it seems agile tools are catching up to the real world demands placed on organizations managing large, complex projects with agile methods—especially those companies who are developing products with shared components. While agile tools have done a great job of connecting teams to help keep even un-collocated team members frequently communicating, the biggest drawback of agile tooling options has been their capacity to translate in complex development environments. For example, it’s extremely common for large organizations to develop applications which are then utilized in multiple products. However, no tool has satisfactorily addressed that issue, making it near-impossible for such organizations to gauge the overall progress of a project, since it includes multiple backlogs.

But ScrumWorks Pro 4, which has just been released by Danube Technologies, has taken some big steps toward giving enterprises the ability to accurately track progress in situations like these. In the latest release of ScrumWorks, its two-paned interface highlighting the sprint and product backlog has been expanded to include a third view: the release planner. The release planner will allow users to define product features at a high level and assign themes (i.e. searchable/sortable tags) to the various products that will utilize this feature. Because programs (or “epics”) are created using themes, ScrumWorks 4 offers highly flexible program management capabilities and, importantly, allows users to configure the tool to reflect their own development activity, rather than work around the limitations of a tool.

If you’d like to learn more about ScrumWorks 4 and its features, head here.

Posted: September 1st, 2009 under Agile Programming, Scrum, Uncategorized.
Comments: none

If you’ve ever had to convince a manager of the value of agile programming techniques, such as test-driven development and pair programming, you know what an uphill battle that can be. But Mike Bria at InfoQ has just posted an article titled “How TDD and Pairing Improve Production,” which takes those anti-agile attitudes to task. In response to such common criticism of pair programming as “twice as many people writing half as much code,” Bria turns to Mike Hill who identifies the key to boosting productivity as a matter of improving internal quality, citing the following three proof points:

1. “Because internal quality and external quality are not the same things.

2. “Because the biggest single determinant in today’s production is the quality of yesterday’s production.

3. “Because typing is not now and never has been the bottleneck in writing code.”

So what steps can development teams take to ensure that their internal code maintains a high level of quality? Again, Hill provides the answer with three more things to consider:

1. “Write a microtest that fails before you change any code.

2. “Adopt a “no-pair no-keep” agreement.

3. “Establish a shared understanding of internal quality.”

You can take a look at the entire article here.

Posted: August 21st, 2009 under Agile Programming.
Comments: none

I’ve pointed readers to a list of books on lean and agile lately, so here’s another one to consider. Reviewed by Brad Appleton in the Agile Journal, The Art of Lean Software Development: A Practical and Incremental Approach by Curt Hibbs, Steve Jewett, and Mike Sullivan receives a favorable review. However, Appleton takes pains to make sure that readers—especially long-time readers of the Agile Journal who may be advanced agile practitioners—understand that the authors’ wrote the book as a primer for the complete novice. But having said that, Appleton recommends the book on those grounds. Yes, it claims to be a basic introduction to lean and agile, but that’s okay because that’s exactly what it delivers. At this point in agile’s maturity, a solid introduction to the most important parts of the puzzle is always in demand.

Read the entire review here: http://www.agilejournal.com/articles/17-articles/1746-featured-book-the-art-of-lean-software-development-by-curt-hibbs-steve-jewett-and-mike-sullivan

Posted: July 1st, 2009 under Agile Programming.
Comments: none

As Dr. Dobb’s reports, there’s a group of software professionals who have added an addendum of sorts to the Agile Manifesto, which they have dubbed “The Manifesto for Software Craftsmanship.” You can take a look here: http://manifesto.softwarecraftsmanship.org/

Just as the Agile Manifesto identified a set of priorities for a new approach to software development, this manifesto further refines the criteria. As they explain it, software should not only be working, but well-crafted; development should not just respond to change incrementally, but also add value incrementally; individuals and interactions may be privileged, but they need to emerge as a cohesive community; and customer participation is not enough, it needs to result in “productive partnerships.”

I’m sure that devout agilistas would regard this development as consistent with agile’s commitment to inspect and adapt. But are the distinctions made here valuable or do they just amount to semantic quibbles? Personally, I see some of the language as moving closer toward a precise articulation of what the original manifesto sketched out, but, at other times, it seems like splitting hairs. What do you think?

Posted: April 17th, 2009 under Agile Programming.
Comments: none

One of the aspects of agile that makes it so popular with development teams is that—at least within the boundaries of a sprint—a team is left to make its own decisions about how it completes its work. It’s a lot of responsibility for the team, but, when the team is empowered to self-organize, its members tend to take more ownership of the work to be done and experience more satisfaction when it’s successfully completed. It’s really simple psychology. Nobody likes someone looking over their shoulder and bossing them around. When a developer can dictate his or her own course of action and see how their decisions positively impacted the business, then everybody wins.

But what else motivates us? By and large, our most deep-seeded motivations are personal. We all have our own definitions of rewarding work. Interestingly, Jurgen Appelo surveyed a group of developers and found that what inspires them can be as idiosyncratic as our tastes in food, music, or the opposite sex. You can take a look at the whole list here: http://agile.dzone.com/articles/what-motivates-some-us, but here are a few of the best:

• The main part of my motivation comes from knowing that I can implement things that make people’s lives easier. (Jeremiah Dodds)
• When I am so absorbed in my work that time flies by and I suddenly realize that 4 hours have gone by when it only felt like 10 minutes. (Russell Ball)
• When I meet someone who actually uses our web sites, and really, really likes them. (Jan Miczaika)
• Trust from a manager. I am especially referring to the time after a project is completed… if the project was done successfully, being trusted with another critical project and more responsibility on the project. (Brad Schafbuch)

Posted: February 12th, 2009 under Agile Programming.
Comments: none

I don’t know about you, but it seems like there’s always a stack of books on my desk or nightstand that I’m just not getting to. And given the rise in agile’s popularity, there are too many books on agile and development, in general, for me to keep up with. So when I saw this very short list by Meera Subbarao of the five best books she read last year (http://agile.dzone.com/articles/the-top-5-books-i-read-2008), it seemed like a tailor-made cheat sheet. Here’s her top five:

• Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
• Effective Java, Second Edition by Joshua Bloch
• The ThoughtWorks Anthology by ThoughtWorks
• Java Power Tools by John F. Smart
• Groovy Recipes: Greasing the Wheels of Java by Scott Davis

Posted: February 10th, 2009 under Agile Programming.
Comments: none

Even if the economy has looked a little up in the New Year, the threat of a recession is still weighing very heavily on everyone’s minds—especially business owners. Of course, what everyone wants to know is how they can weather the global economic crisis without losing market share or watching profits take a nosedive. More and more, I’m seeing business leaders and analysts point to project management frameworks such as lean, agile, and Scrum as the answer. And while the reality of changing the way your company works could create some short-term challenges, agile management practices can yield incredible savings and results over time.

In a recent post titled “Mastering the Recession with Lean, Agile, and Scrum” on www.agilesoftwaredevelopment.com, blogger Peter Stevens considers how agile methods can steer organizations toward lean operations that can both withstand hard times and flourish when the recession loosens its grip. The first piece of indispensible advice is “create value for your clients.” In fact, this should be the shining beacon that illuminates every one of an organization’s activities. If you’re focused on building something so peerlessly useful, created with your customer’s needs in mind, then your customer won’t be able to deny its value. And in that situation, they won’t be able to afford not to retain your services or use your use your product.

The second pearl of wisdom is to “eliminate waste.” This concept is more closely linked to lean manufacturing than to either Scrum or general agile, but, really, it’s like dealing with two sides of the same coin. The benefits of eliminating waste are twofold. In the midst of the recession, it helps organizations to focus its business on those activities that create the most business value, even forcing management to acknowledge branches of the business that are not bearing fruit. This process of organizational streamlining pays off over time, too. If a company reconfigures itself to survive during challenging times, imagine how that same configuration will operate when customers aren’t guarding their coffers as closely. Suddenly, a team guided by its attention to its customers’ needs that effectively reduces waste is prepared to succeed in both good times and bad.

Posted: January 16th, 2009 under Agile Programming.
Comments: none

With the economy tanking, many companies are finding themselves trying to identify ways to maximize resources and operate as leanly as possible. One solution that organizations, particularly those in the software development industry, are exploring is agile project management. Agile has earned a reputation for yielding highly performing teams who can create a product that customers truly want. Over time, that combination of great teams and targeted deliverables does translate to reduced costs and cycle time, but organizations should understand that agile methods are not implemented quickly and easily. Yes, transitioning to agile is a great long-term investment toward becoming sustainably resourceful, but it’s definitely not the answer for companies looking for a quick, painless fix.

Perhaps the biggest reason agile—and Scrum, in particular—can achieve its results is through ongoing communication. Agile’s employment of iterative, incremental work cycles ensures that the customer is continually brought into the development process. Factor in that agile asks developers to produce a potentially shippable increment of work (a functional version of the product, however skimpy its feature set may be) each Sprint and the team is prepared to demonstrate its work for the customer as often as every iteration. Such a short feedback loop prevents the team from blindly pursuing an approach that conflicts with the customer’s vision and, to be somewhat redundant, leads them toward the customer’s particular requirements faster. I understand that those last two points are, in essence, two ways of saying the same thing. But it’s important to understand how agile enables efficiency; it does so by empowering its team—through directed feedback—to do its job effectively.

Sounds great, right? It is, but here’s the rub. In order for teams to begin operating in this way, it’ll likely take time for them to acclimate to these new principles and processes. For example, because agile demands that the team produce a potentially shippable product every Sprint, the team will need to address defects that would prevent the product from being demonstrable for the client. That is, the team would need to fix the products’ bugs in the same Sprint that they’re discovered. That affects how much work a team can accomplish in a Sprint, since now it must perform the additional work of fixing bugs as they pop up. Considering that the number of bugs tends to increase with the size of the codebase, this mandate will force teams to decrease the amount of work they can handle in a Sprint. However, consider the upside. Rather than sequestering bug fixes to the end of the development cycle, the team maintains clean code and always knows where it stands in terms of progress. Rather than a chaotic conclusion to the development cycle, in which the team attempts to patch up all defects in one fell swoop, this approach forces developers to deal with critical bugs before adding more functionality. That will definitely result in more work in the short-term, but, over time, that combination of customer input, frequent communication, and vigilant code maintenance will result in doing more with less.

Posted: December 19th, 2008 under Agile Programming.
Comments: none