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.
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? Continue reading
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. Continue reading
Pair programming is a technique where two programmers work at a single work station. One person “drives” or has control of the mouse and keyboard. The other person “navigates” or keeps track of where they are and where they are headed. This is a perfect environment for teaching and learning to occur.
Newton’s Third law of motion, “To every action there is always an equal and opposite reaction…” is a powerful standard in analyzing team dynamics. I have been leading agile teams for over five years. When I am asked to lead a new team I begin by looking for reactions that are disproportionate. While this may seem like a strange place to focus this is a simple way to identify significant areas of improvement.
Time and time again, I have uncovered issues that have been ignored and/or hidden by exploring “over reactions”. They are indicators that there is more to the story. For example, one of teams that I was leading was very frustrated with how much time we were spending estimating stories. Their frustration eventually culminated in some of the team members refusing to participate in team estimation meetings. As you can imagine this created significant tension between the developers and the business team.
Everyone, especially project managers, is in love with Agile Development. And why wouldn’t they be? Under the old school system, you’d end up with developers either sitting around uselessly, or drafting up prototypes that will only be thrown away. Agile allows for parallel design and development, wasting less time and money. But there’s always a tradeoff. In this case, I’m thinking of commonality of design. Let me explain by example:
I’m currently working an Agile project with three developers including myself. We’ve divied up the tasks so that one is doing the JSF database plumbing, and the other two are creating the web services that sit on the back end. We started development without having a certain idea of certain database keys, so we naturally wrapped the keys in an object that we could easily change when the decision was made. It let us move forward with development and had a very low cost for change when business came back with a decision. But we each implemented it in a difference way, using a different nomenclature and at different times. So now we have three objects that perform identical tasks, and require a translation process when our respective parts interact with each other. It’s not broken, but it’s definitely messy.
And it’s a natural fallout of the tendency to think that Agile means you start developing right away, and things like requirements and interfaces can be laid on top of the code later. How do we prevent it? Sadly, communication is the only answer. Code reviews early on could have prevented this situation before it would have been a pain in the tuckus to refactor. A project wiki exists, and even has a section that lays out common objects and interfaces. But the wiki was infrequently referenced for matters of actual code implementation; it was for the documents and the Agile storyboards.
In the end, it’s important to recognize that Agile development has taken the large chunk of communication out of the beginning phase of a project. But that communication isn’t gone, it’s been spread out over the duration of the project, and in most cases that means there going to be a lot more of it. As developers we eagerly embrace Agile projects since it means we don’t spend two months in design meetings and can’t indulge our love of code early on, but we have to realize that it comes with a cost. We actually have to talk to each other.