kentoh - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Agile Manifesto: Readers refute 'anti-planning' idea

Jennifer Lent examines the backlash from her last month's column that suggested the Agile Manifesto promotes anti-planning.

Does the Manifesto for Agile Software Development still matter? I posed that question in a recent column and the responses from readers came back loud and clear. My original post argued that the Agile Manifesto is outdated with respect to how it addresses the need for project planning versus the need to get real work done. But readers took issue with the idea that the Agile Manifesto is anti-planning.

"Let me put it this way: I don't think the [Agile] Manifesto is going out of style anytime soon. Its core elements remain accurate and useful." That reply, from a poster identified as jamesz243, was typical of the many received from SoftwareQuality readers, who posted comments on our website, on ITKnowledgeExchange and by email. "The model [put forth by the Agile Manifesto] is still relevant and will continue to evolve," wrote another reader, ImLoggedinAlready.

Collectively, readers' comments made clear that they -- and perhaps software pros as a whole -- see the Agile Manifesto as an inspirational document, not a set formula for developing software in an ever-shifting business and technology environment. They believe the Manifesto's four core values and 12 principles remain as relevant today as they were when the authors wrote them down in 2001.

In this edition of Quality Time, I share reader responses to my original post about the Agile Manifesto. I focus on those who insist I got it wrong when I said, "When it comes to managing projects -- going with the flow instead of following a plan -- the Agile Manifesto is outdated."

Agile Manifesto: Not anti-planning

"Wow, what an interesting article, and I couldn't disagree more," wrote one poster who identified himself as Veretax. "Agile doesn't say you shouldn't plan, it says you should do it more often, and in discrete increments."

I don't think the Agile Manifesto is going out of style anytime soon. Its core elements remain accurate and useful.
Jamesz243SearchSoftwareQuality reader

Another poster -- mcorum -- elaborated further. "I have to agree with Veretax that [the Agile Manifesto] doesn't mean don't plan, it means plan and adjust that plan as necessary to respond to change, which is quite different from going with the flow." Posting on ITKnowledgeExchange, Bhart89 agreed. "Agile isn't about less planning but it is about being responsive (even seeking out) those inevitable changes that occur during a project."

So, I stand corrected. My initial take -- that the Agile Manifesto is anti-planning -- was wrong. The Agile Manifesto doesn't say move away from planning. It simply says delivering more work is more important than delivering more plans. One poster succinctly captured just how challenging that is. "We need plans for various reasons (budgets, stakeholder communications, large project or programme [European spelling] management, etc.), but these plans should be adaptable and should add value to a project, not constraints," wrote Ernesto Amato, an Agile project manager in Milan, Italy [his post appears on ITKnowledgeExchange].

Agile Manifesto: Face-to-face conversations

More than a few comments pointed out the communication challenges experienced by far-flung teams. "As far as face-to-face conversation goes, a lot of tacit communication can still be lost because you don't sit near the people you work with," Veretax wrote. "But software like Skype, Google Hangouts, and [Microsoft] Lync, not to mention Web conferencing software of many kinds, go a long way to helping bridge that problem for teams that are remote."

Agile isn't about less planning but it is about being responsive (even seeking out) those inevitable changes that occur during a project.
Bhart89SearchSoftwareQuality reader

Another KnowledgeExchange poster, abuell, noted that working on a distributed team is a fact of life. Referring to one of the 12 Agile principles, this reader wrote: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. In fact, I probably believe that now more than ever. Remote communication, with technology snags, time zones, and language barriers, always adds some amount of difficulty."

While I can't imagine the Agile Manifesto's authors had multi-team, multi-location projects in mind, the ideas they set forth nearly 15 years ago remain meaningful today. Veretax said it best: "I'm convinced that the ideas in Agile help bridge the communication barriers and improve development processes, and the value of what is produced."

Improving the value of what is produced -- delivering better software -- is the point.

Thanks for weighing in. Let me know how you manage communication challenges among far-flung Agile teams.

Next Steps

Discover the connection between Agile, SOA and microservices

Find out how Agile and DevOps mesh with the cloud

Get the lowdown on agility-based tools driving the hybrid cloud

Learn Agile ways to manage continuous requirements

This was last published in April 2015

Dig Deeper on Agile Software Development (Agile, Scrum, Extreme)

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

5 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Jennifer, I must applaud you for the humility you exhibited in modestly acknowledging misgiving. With regards your question on managing communications with far flung teams, I haven't worked on a such a Project. Hearty cheers.
Cancel
I definitely do not think that following the Agile Manifesto implies that you do not plan. But I do think that Agile in general gets teams into modes where planning falls by the wayside. And I am referring to longer-term strategic planning. At least that has been my observations.

I have seen teams get all gung-ho about Agile and start moving fast and efficient. But these teams get stuck into modes where they only see the world through the soda straw of each release. Iteration after iteration they march forward and improve their product but they do so in small steps. This prevents them from implementing anything grand and instead gets them into modes where they are just adding bells and whistles.

Now, you could argue that these teams are probably not implementing Agile "properly" but these teams would disagree. And these teams' management would disagree too. They are pleased with the output of the teams. But when assessing these teams' progress over a multi-year term their overall achievements are not that impressive. I believe that long-term planning, or the lack thereof, is responsible for this.
Cancel
There are five levels of planning in Agile methodologies: product vision, product roadmap, release planning, iteration planning and daily planning. The product vision is the link to strategic planning. Some teams use the product roadmap also.
Cancel
My team has struggled to find a good balance for planning. 

JimJamesone, you have valid points, but usually the team is not going to be responsible for that kind of very high-level, multi-year planning. At least in my company, that comes from high above us.  When a project has been prioritized on the product roadmap and handed to our team, then it's our responsibility to figure out a design and implementation, and plan the project into our iterations. That's the part where I feel like we haven't spent enough time on planning for some projects.
Cancel
How do we manage far flung teams.

1. Have a culture of responsibility and accountability... That means trusting that devs, testers, and other contributors will try to do their work in the most responsible way possible.
2. Have a regular tag up time during the day to check in.  (Scrum calls this the daily scrum).  It isn't just about what happened, is happening, will happen, and blockers, its a chance to get more idea of how all the little pieces will start to fit together.
3. If you have a question, ask someone, don't sit there and be blocked all day (This applies to in office work as well)
4. Provide mechanisms for regular communication, whether its email lists, chatrooms, or hangout calls to action.

The reality is, that remote work can be very rewarding, and people who are good at it know that they have just as much responsibility to follow up with the other people, as those who are sitting in an office together.
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close