Agile Programming

How can a group of people – all of whom are individually capable and reasonable, form a team that is incompetent and unreasonable?  This is an intriguing topic being discussed on the Scrum Alliance Google group site.    Normally when we think of teams we think of a “greater collective intelligence” or how the “whole is greater than the sum of its parts”.   However, sometimes teams can also be “incompetent”, “unreasonable” or dysfunctional.  How can that be if the individuals within the team are not that way?  One view being expressed by the person that raised the topic is that team problems are often caused by people being afraid to open up about uncomfortable truths.  During meetings they will nod their heads in agreement, but in private, they fume.    Is this because they do not know how to voice their disagreement in a non-confrontational manner?  Or is it because team members do not have transparency into the complete status of the project and what other team members are doing and therefore their decisions may be biased due to lack of information and empathy?  Scrum tools and agile games are great because they address these “people issues”.     Using Scrum helps to create an environment of transparency which in turn leads to better communication and understanding among all team members .    If you have an opinion on this topic – jump into the conversation.

Posted: June 4th, 2010 under Agile ALM, Agile Programming, Scrum.
Comments: none

In a blog post on the SDTImes website (“Agile Making ALM Teams Work Faster, More Open”), Jeff Feinman takes a moment to share one aspect of a larger article he’s working on about agile life-cycle management (ALM), but that one aspect is a big one. According to Feinman, as he’s surveyed dozens of ALM companies about how they deliver their processes, ALL of the companies he’s talked to report that “100% of their customers are at the very least thinking about adopting agile processes.”

Though agile has soared in popularity over the past year or two, this is still a staggering update, illustrating just how widely agile adoption truly is. Still, one enduring impediment to adoption is the desire for organizations to implement a tool, rather than a process. Anders Wallgren, CTO of Electric Cloud, explains: “Part of what takes a thing like agile some time to get adopted is, I think, naturally, we want to buy a tool, not a process. So if I hear about this thing called agile, I’ll say well, ‘Where do I buy the agile software package?’ It’s a little difficult to get people to change their processes.”

Of course, some tools are designed specifically to reinforce that process. As I’ve mentioned here before, my team manages its projects using Scrum. Because Danube’s tool ScrumWorks Pro was created with the framework in mind, it complements my team’s activities perfectly, while giving new team members a guide rail to help them follow Scrum’s processes.

Posted: March 17th, 2010 under Agile ALM, Agile Programming, Careers In Scrum, Scrum.
Comments: none

Longtime readers of this blog know that I’m a big proponent of Danube’s project management tool ScrumWorks Pro. The company released a major release back in August (ScrumWorks Pro 4) that added some exceptionally flexible program management capabilities to the tool, but, since then, they’ve been issuing point releases at a swift clip. One of the reasons for this is their new Community Portal, a forum where ScrumWorks Pro users can communicate directly with the tool’s Product Owner and Development Team as well as one another. There, users can suggest features to be added in future releases, vote on other users’ ideas, or simply post a question they need help with. When I first heard about it, it sounded like a great idea—a way to create a true community of Scrum users who can work together to continually improve the tool. But now the fruits of Danube’s labor are starting to show. For example, if you head here, you can actually see what features have been implemented in the tool based on the conversations generated on this forum. Very cool.

What I especially love about this concept is that it actually shows how Danube uses Scrum and agile processes and values to shape ScrumWorks Pro. For instance, the Portal acts as a great information radiator—any user can quickly see what’s being worked on and who’s discussing what ideas. Likewise, it offers the Development Team an abbreviated feedback loop, so they’re always calibrating their product direction based on the emerging needs of customers. It makes me happy to see a Scrum company putting its money where its mouth is!

Posted: December 9th, 2009 under Agile Programming, Scrum.
Comments: none

If you’re a seasoned agile practitioner, you’ve likely got a whole treasure trove of best practices at your disposal. But if you’re just getting started and trying to make a clean break with traditional management practices, you might benefit from this list of “26 Hints for Agile Software Development” compiled by Keith Swenson. They range from the general/philosophical (“Eliminate waste”) to more granular, engineering-oriented advice (“Never add a data member before it is needed in a use case”). For the uninitiated, this list covers a lot of the bases. Check it out!

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

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