What is Agile Development?

October 31, 2013

Here are some of the responses that I’ve heard over the years:
  • It’s a mindset or a philosophy.
  • It is the values and principles of the Agile Manifesto.
  • It is a framework rather than a methodology.
  • It is a way to get more features out the door quicker than ever before.
  • It is something that the development teams do.
  • Agile development is anarchy! (I haven’t heard this one lately).
Perhaps you have a variation of one of these in mind, or even another, very different definition. Perhaps you’ve heard of technical practices like Test-Driven Development (TDD). What does all of this mean?

One of the challenges with agile development is that it defies being meaningful y described in a sentence or two. I’ve tried, but I never liked the results. I’ve also heard people criticize agile development because it can’t be defined succinctly.

Our Beliefs Box Us In with Software Projects

October 24, 2013

“Doctor, every time that I do this, it hurts! What can I do?”

“Well, don’t do that anymore!”
– Old Joke
Why do smart people continue to do things that hurt when it comes to software projects? Because we’re human; and as humans who have been actively and continually working at improving our software development efforts we have come to believe certain things. Those beliefs are in turn reflected in what we value. And because we value certain things, these values are incorporated into the approaches and practices that we subscribe to as a means of achieving success.

If we believe software projects are predictable, for example, then we value the process of planning, which leads us to implement an approach and practices that support gathering information and planning in detail up front. (Mezick, 2012)

This is also why it becomes a challenge to change. As humans we want a balance between what we believe and value and our behaviors and actions. If there are inconsistencies, we will find ways to eliminate those inconsistencies. (Keller, 2011)

Software Projects Never Go According to Plan

October 17, 2013

My previous post walked through a common software development scenario where everything appeared to be well-planned at the beginning of the project, but as work progressed, the project came off the rails. This is a common scenario because software projects invariably fail to go as planned. Figure 1-2 depicts how we envisioned the process:

Figure 1-2

Our expectation was that we could define our requirements fully up front and send them through our product development pipeline where those requirements were augmented with designs, transformed into working software, validated and ultimately delivered using a crisp, well-defined sequence of steps – all executed according to plan. However, our experience proved that things don’t work this neatly in actual practice.

One problem was that as work got into that pipeline it got bigger than what was originally planned, clogging the pipe in some cases. Our initial estimates were off because we lacked critical information about the users’ true needs. We uncovered those needs as we implemented features. This meant that our initial certainty about the requirements and the confidence in our planning based on those requirements was actually misleading.

Agile and The Need For Change

October 9, 2013

This post contains draft of content intended for an upcoming ebook: Agile Expectations: What to Expect from Agile Development, and Why. Blog posts will be organized under the “Agile Expectations” content on the left-hand side for easy reference. I welcome your comments and feedback! – Dave Moran

Before we talk about what agile development is, why are you considering it? Is it because agile development is the new, cool thing to do? If the cool kids are all doing it, we won’t look good (cool) because we aren’t doing ourselves, right?

As agile development has gained momentum in recent years there seems to be more comments about internal pressure “from above” to adopt agile in organizations, despite limited knowledge about just what being agile is all about. If this is where you are, this guide will help you understand what agile can do for you.

Perhaps you already have some very specific reasons for adopting agile development. In other words, you are dissatisfied with the status quo in one or more ways. In that case, this guide can confirm that your own dissatisfaction has merit and that agile can indeed help your situation.

Agile Expectations: Introduction

October 3, 2013

This post contains draft of content intended for an upcoming ebook: Agile Expectations: What to Expect from Agile Development, and Why. Blog posts will be organized under the “Agile Expectations” content on the left-hand side for easy reference. I welcome your comments and feedback! – Dave Moran

The inspiration for this guide comes from my own agile journey that began with one development team in 2005, quickly migrating to all of our teams. In fact, the title of this guide began life as a document I started with our management team early on during our agile adoption.

In 2005, I was working for a software company as the Director of Software Development. We had just completed development of a large, complex product that no one in our organization felt was a rewarding, satisfying experience. The only satisfaction came in claiming victory; claiming being the key word.

We had a lot of fixing up to do. The schedule pressure had been enormous, the requirements continually shifted throughout the development effort and sections of the code – despite this being a 1.0 release – really needed re-factoring. The pressure to cram too many features into a first release had led to inevitable shortcuts by tired, overworked, desperate developers.

It was this team that approached me about trying agile development. I’ll confess that I didn’t know that much about agile development at this point in time. I had heard of it and read a little about it, and I had even attempted to learn more a year or so prior to this from some XP (eXtreme Programming) developers that I met at a development conference.

An Agile Project for Me and a Sneak Preview for You

October 2, 2013

I have ideas for a couple of books on agile. For the past four years I’ve been writing about agile on this blog (and other blogs here and there) along with publishing some articles on the side, so this seems like a good next step. I’ve actually pushed off suggestions in the past to write a book, but right now, the timing feels right.

I’ve got notes and thoughts on the direction I want to take, but time is a precious commodity for me as it is for all of us… So I want to write my first book while I continue with this blog and earn a living. (My blog does not earn me living!) The simplest and most direct thing to do is to a) write the shortest book I have in mind first, and b) draft my book in public, using this blog.

The book I have in mind is something that I can hopefully self-publish and make available fairly quickly. The goal for this book is to answer the question: What is agile and what should you expect from agile?

My tentative title for this book is: Agile Expectations: What to Expect from Agile Development, and Why

I’ll make another post tomorrow, starting off with what will be the Introduction to the book. I will organize the material in chapter format on this blog as I’m writing it. This will be the sneak peak for you. Once I’m complete, my intent is to package the material up and publish it – provided that I’m satisfied that the content is indeed worthy of publishing.

As always, any feedback on what is working and what I need to improve is always welcome!