Agile Perspective

Tim Broyles Agile, Dev Methodologies 1 Comment

Attention: The following article was published over 6 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.

Ahemm.. is this thing working?

You may think of Agile as just another process. While this is incorrect (as it is a framework created to help developers create processes), there is a fundamental difference between this methodology and most methodologies that have come before.

Agile–done the way it was intended–is revolutionary. Fundamentally, Agile is an advocate of a bottom-up development process. I believe this is why it is often proposed with good intention, however then implemented with a top-down, fixed idea of what the Agile team (and hence the process) will be like.

If you take time to read the Agile Manifesto you will read statements like: ”The best architectures, requirements, and designs emerge from self-organizing teams.” Just consider that for a second. The team has the power to keep what works and dispose of what does not.

There are some basic concepts that allow Agile development to be successful. In this post, I highlight the key parts of Agile that appeal to me (as a reluctant process advocate) and have enabled successful Agile development in recent projects.

Author Bias & Agile Career Experience

Before I do that though, I would like to expose my personal process biases.


My first exposure to the development process was working for a division of an organization with an exceptionally high reliance on defense contracting. This government division of Rockwell (Collins Avionics and Communications Division) had a primary process for software development named DO-178B. Here is a visual overview of that process.

You can see that this is a classic waterfall. There are lots of requirements for design, coding standards, unit testing, quality testing. Each stage has gates, each gate opens up the next stage, etc.

It was a very successful process for safety and mission-critical applications. However, this obviously is an ocean liner; once it was on the move, changing course takes time to re-initiate the process for the refinements, which is expensive in time and cost to the overall system.

No Process

Enter the no-process extreme. For a number of years, I worked at a biotech startup that made its mark during the 2000 anthrax scare.

My company developed a mechanical biotech air sampler that converted the airborne particles into a collection of soluble vapors which could be easily processed in a biotech lab. The software was outsourced; I was brought in to create a process for bringing the development process back in-house.

You may be able to imagine that in a startup, the overall process for product development was a bit chaotic. Take the first three gates from the diagram above and jumble them up where design often proceeded planning, and requirements often were generated while coding.

Many of you may have experienced this in larger organizations as well. The problem is in my observation, that we think we know what to do before we consider what we are doing. To be clear, I believe the gate sequence of the D0-178 process is correct for converting an idea into a product. However sound the idea, the government process is labor intensive and filled onerous requirements of how each gate must be approached and completed.

For the majority of projects, however, flexibility and creativity are the operative ideas for conceiving a path from concept to creation.

During this last experience, I became acutely aware of the necessity of process. The accountability the process brings directly informs the predictability of the product’s lifecycle. I did not feel the full waterfall methodology really worked for a small startup, however, the gates from my original experience stuck with me and I found they always existed in a successful lifecycle of a software project.


At a later time, I was contracting at a large organization undergoing the process change to Agile development. Different parts of this matrixed organization had different forms of processes for requirements, design, development, etc.

Typically it involved very waterfall/ad-hoc processes that had been formalized in some way, but with lax enforcement. All that was important was that the product was delivered reasonably on schedule. There was a PM (Project Management) group in this organization, which in my view would be responsible for enforcement of the process, but the evidence that this happened was not very clear.

So, one day the VP gets on the Agile bus and declares we were to convert our development process to Agile. He stated that coaches were coming in, they would train us, we would measure our velocity. We would tame the beast that took 20 or so years of legacy to produce.

At this organization, the majority of the training went to the project managers, who also became the product owners and the Scrum Masters. This is a violation of the Agile concept of keeping managers out of the process.

Basic Agile Concepts

I am not Agile apologist. However, there are some basic concepts that I believe allow Agile to work successfully.

There have been a number of software organizations I have contracted with that have implemented Agile in various ways. In my experience, there are few that have provided an implementation that is different from a traditional waterfall approach.

I find myself currently at a financial organization that may indeed have the transition from ad-hoc/waterfall to Agile figured out. It is early in the process, just seven sprints in. This is what I can observe that is working well.

The “manager” is no longer.

  • Instead, the Product Owner provides a backlog and requirements to the team.
  • The Scrum Master keeps the team on track.

The team is self-organized.

  • Self-organizing teams are more efficient.
  • Agile is a framework involving what amounts to suggestions on how to run a development team using an accountable efficient process. If the team is not in agreement, it does not work.
  • Remember, Agile is not a process, it is a framework. What pieces we use and how we used them is determined by the team. If we want to use Fibonacci numbers for our story points, we can do that.
  • Educate the team, trust them (add some guidance), and after a couple of sprints, the organization of Agile team will show improvements. Efficiency will continue to improve through the stages of team development and cross-training.
  • If our retrospective is every two sprints or we want to skip one, no alarms go off. Get out of the way and trust the team to get the job done

The process is respected.

  • Sprint planning respects capacity and slack.
  • Backlog refinement is performed on a regular basis.
  • Management is hands off, apart from providing assistance to the Scrum Master when altitude for resolving issues is required.

The Scrum is a scrum, not a status meeting.

  • “What did you do?”; “What are you doing?”; “Any blockers?; …NEXT!”
  • Monologuing is prohibited (seriously).
  • Use a follow-on meeting if necessary.

Tools are not necessary, but a good toolset makes the journey more enjoyable.

  • The lifecycle of artifacts necessary for and editing/tracking/monitoring Backlog items used to create stories and tasks should be painless.
  • Story and task assignment really helps the accountability on your project, so use this feature to burn-down your task hours and record blockers, swarm tasks etc..
  • Development check-ins (to a revision control system) tied back to the story is a nice feature. (Note: JIRA has this, VersionOne does not). This is also helpful when it comes time to release the product or merge features for release.


There are many detractors of the Agile methodology. Some of them may say, “it’s just another process, just wait six months to a year and we will be right back to where we are now.”

If this is you: that ship has sailed, it’s time to get on board. Still, others may find that this is a similar process that they have been using, but without the additional ceremony.

Final Thoughts

It is my opinion that Agile leverages what software development practices we know to be good, like short, incremental delivery times; collaboration with stakeholders; storming issues with multiple team members; cross training…

Agile keeps the focus is where it should be: on the delivery. Events that support this goal exist in Agile ceremonies like backlog refinement, spring planning, and standups.

The shortcomings, as with all processes, is the overhead. The meetings (ceremonies) could become counterproductive. The Agile method requires that these be short and focused.

Just remember that we are self-organized teams that make our own rules.

What’s in your process? ™

Recommended Links

Many Thanks

Often overlooked: a great post is not written, it is revised.

If this post is laid out in a reasonable fashion, concepts follow and build on each other, and it presents a cohesive idea, it is due to the diligent editing and suggestions from our very own Lauren Fournier. (Editor’s Note: Thanks for your kind words, Tim!)

5 1 vote
Article Rating
Notify of

1 Comment
Newest Most Voted
Inline Feedbacks
View all comments