Category Archives: Agile

Agile Iowa No Estimates Puzzle Experiment

cecil-presenting-agile-iowa-puzzleI facilitated my own rendition of the #NoEstimates Puzzle Experiment for the September 2013 Agile Iowa user group meeting. This experiment was created by Chris Chapman to generate critical thinking and conversation concerning whether estimates are necessary to produce quality software. The meeting had a great turnout, with around 40 people attending during a Midwest thunderstorm that left over 20,000 people without power.
Cecil Williams
Cecil Williams

Latest posts by Cecil Williams (see all)

Continue reading

Pragmatic Application of Principles

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.

Latest posts by David Kessler (see all)

It is not wise to apply (a) principle … if there is no symptom.

Continue reading

What you missed at Agile 2013

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.

Cecil Williams
Cecil Williams

Latest posts by Cecil Williams (see all)

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.

Continue reading

Agile Manifesto – Responding to Change Over Following a Plan

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.
Cecil Williams
Cecil Williams

Latest posts by Cecil Williams (see all)

Traditional Software Development
Traditionally, software development teams viewed the cost to change something as increasing over time.  To save money these teams required customers to define everything they wanted before they ever started building the system.  While this sounds reasonable, we all know that something will always be missed.  These missing requirements will creep into the project little-by-little.
Many organizations try to prevent changes by making it very difficult, if not impossible, to inject changes after the initial planning phase.  This resistance drives many teams to add everything, including the proverbial kitchen sink, to their initial requirements to avoid the pain of adding changes later.
While this seemed like a good idea at the time, our industry has learned that allowing change is imperative for companies that must compete in a fast paced, cut throat, rapidly changing marketplace.
The last decade has seen several software development processes become popular that allow for planning and change to happen at the same time.
Agile Software Development
Agile software development processes accomplish this through different levels of frequent planning and re-evaluation. The first and highest level of planning is release planning.  Within release planning, teams agree on the features to include in a release.  At this level of planning, features remain very large.  The purpose of this planning session is to paint a large picture of the project with very large paint strokes.  Once these large strokes are grouped into meaningful releases, we proceed to prioritize each release and then break them down into smaller time periods known as iterations, based on priority order.  Each iteration is typically limited to two week periods.
At the beginning of each iteration we agree on which features the team thinks they can complete.  These features are broken down into stories, which are kept in a prioritized feature list.  By working in iterations, the team has the ability to adjust what they are working on every two weeks.  Thus, if a new requirement is discovered, the team is able to incorporate it without difficulty in the next iteration.
This approach intensifies the investment of planning as the team gets closer to a given iteration. Focusing on a few features intensely empowers us to lock in a limited number of decisions that often uncover information that effects later decisions.  While the old style of up-front planning attempts to uncover these pieces of information early, a significant amount of this information cannot be fully understood until we start to develop and use a working system.  No amount of thinking can replace hands-on experience with the real system.
As the team works in an iteration, the stories are pushed from one stage to the next. The stages vary from company to company, but typically include development, testing, and deployment.
Once an iteration is completed we take time to reflect on what we learned.  This review meeting is called a retrospective.  In this meeting the team discusses what went well, what did not go well, and what changes we want to make.  This meeting helps us learn from our mistakes and make a commitment to improve.
Lean Software Development
Taking the Agile software development process a step further, the lean software development approach focuses on limiting the work in progress based on the constraints of the team. The team cannot push work to the next step.  Instead, the downstream team members pull work into their stage when they are ready to work.
This is done to prevent any one stage in the process from completing more work than the other stages can process. If one stage finishes work and the next stage cannot work on it, then this is considered wasted inventory. Lean software development borrows the theory of constraints from lean manufacturing, in that it limits the work in progress to the slowest stage in the process.
By limiting the work in progress, teams are able to identify bottlenecks in their process.  These bottlenecks may be due to resources, bureaucracy, time, distance, or any number of reasons.  Lean software development teams focus on eliminating their bottlenecks so that they can function at their optimum.
Lean software development processes do not use fixed time periods like iterations.  Instead, a lean process will continue to pull work at the rate that it is capable of producing features.  And rather than having a scheduled release, the team will simply release features whenever the team determines is appropriate.
Lean Startup
Teams are starting to go even further than the lean process, by combining the lean process with ideas from startup companies.  These teams are focusing on a single feature and all the variations that a user might do with that feature.  The lean startup process uses value stream mapping to determine what are the most important parts of a feature to the users.  Then they build those parts of the feature and deliver it to the users.  This allows them to get even quicker feedback and validate whether they are building a desirable product.
Final Thoughts
The last decade has seen several software development processes emerge for responding to change over following a plan without creating destructive chaos.  Following an intensely focused plan is far superior to creating a bloated, expensive, “perfect” plan up-front that cannot be changed without adding significant cost.  Responding to change is not only more effective, it is imperative for companies that must compete in a fast paced, cut throat, rapidly changing marketplace.

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.

Continue reading

Agile Manifesto – Customer Collaboration Over Contract Negotiation

By: Cecil Williams & David Kessler

Do you ever wish that companies would trust their employees and business partners instead of insulating themselves with contracts and policies?  For many companies, each discipline operates out of its own department requiring other areas to document exactly what they want and what they are going to do.  This provides a means to assign blame when projects fail.  In stark contrast, Agile suggests that we should favor shared collaborative efforts over ridged, locked-in, contractual obligations.

ThoughtWorks releases ebook on Agile Project Estimation

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.
Continue reading

Code Quality Metrics with Sonar, Part III: Sonar in a Ant-based Java Project

Now we will cover the fun stuff for which we’ve been waiting. In this post, I’ll go over how to setup Sonar for a Java project that utilizes Ant for its build.  I’ll go through the basic steps for installing and running a Sonar instance, and how to use a MySQL database for collecting metrics. Then I’ll go into some details around analyzing a Java project using Ant and Sonar. This involves writing Ant script, pointing to the source codes, analyzing the binaries, analyzing JUnit test cases, analyzing Ecl Emma coverage, etc.

Continue reading

Agile Manifesto – Working Software Over Comprehensive Documentation

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.

Continue reading