Posts Tagged ‘Agile’
I was reminded of a profound truth as I was re-reading Robert C. Martin’s book “Agile Software Development, Principles, Patterns, and Practices”, in C# this time.
It is not wise to apply (a) principle … if there is no symptom.
I was able to attend the Agile 2013 conference in Nashville, TN earlier this month. I had previously attended Agile 2006 in Minneapolis, MN. There was a significant difference.
At this year’s conference, the overall theme seemed to be that teams needed to focus on producing value rather than following a process. Most of the attendees have figured out that the process will only get you so far. At that point you have to figure out how to improve what you are delivering, not what you are doing.
By David Kessler and Cecil Williams
Is it really possible that intense planning and the ability to respond to change can co-exist within the same development process? If you are wondering this, then you are not alone. Clients regularly ask us if Agile software development teams follow any sort of plan or are they just feel good, free for alls? In this article we explain the types of processes that can be adopted to allow your teams to plan while still responding to change.
ThoughWorks Studios has released an ebook titled “How do you estimate on an Agile project?” where they explore common approaches and their adaptions from real-world projects. The book is comprised of several authors, most notably Martin Fowler. In this ebook they discuss why teams estimate, different methods that teams use to estimate, and provide a couple of case studies.
» Read more: ThoughtWorks releases ebook on Agile Project Estimation
Over the last year or so software development estimates have become a popular topic. The popularity stems from the inherent fact that estimating software development is difficult. Some people are writing about ways to improve your estimates while others are writing about how to manage software development without estimates.
Do you sometimes feel like your team spends more time documenting your system than building it? One of the biggest hindrances to progress in a software project is documentation. The Agile Manifesto prescribes that teams should value working software over comprehensive documentation. It doesn’t mean that you should not create documentation; it means you should create documentation that provides value and at the same time does not hinder the team’s progress.
David Morgan and Cecil Williams, March 25, 2013
One of the biggest hindrances to progress in software projects is bureaucracy. Rigorous processes that must be followed unswervingly, deliverables changing hands between independent groups and required approvals – hand-offs, sign-offs, and stand-offs – all get in the way of software projects making valuable progress. So how would you change that? » Read more: Agile Manifesto – Value individuals and interactions over processes and tools
David Morgan and Cecil Williams, February 25, 2013
How many times have you been presented with a phone book-sized printout of ambiguous yet carefully crafted requirements? How many times have you, swamped with remaining work and short of time, camped in your cubical to meet a looming deadline? Or seen your customers paralyzed by an approval process out of fear that they will not think of everything up front? Or witnessed an organization trying to contain costs “next time” by more strictly observing the same process as last thinking it wasn’t the process that led them astray but their lack of discipline?
If you’re answering yes to some or all of these questions, you’ve felt the pain that can happen during Waterfall (or defined process control) managed projects. » Read more: Manifesto for Agile Software Development