7 agile development trends

4. Lean

I’ve been a proponent of the application of Lean Thinking to the Application Lifecycle Management spectrum for more than 15 years. There are a lot of reasons lean thinking works in software development and I’ve often stated: “Lean describes why Agile works.” We’re going to see an increased velocity of lean thinking applied to software development, specifically in its relation and interaction with the business.

To some extent, some of the things I’ve already been talking about have been heavily influenced by lean thinking – specifically the greater focus of DevOps in agile. In addition, books such as Lean Startup demonstrate that lean thinking combined with agile and incremental practices made really great business sense. This is just one example of how lean will not only ‘sneak’ its way into our way of developing software, but how it will be used to help unite some disparate worlds.

Beware, however, of the lean hype trap. I’m seeing a lot of organisations switch their marketing from agile to agile/lean very quickly and I suspect that this is due to the overall market trend. Years ago (and still to this day) many misunderstood agile in the same way lean is likely being misunderstood. I’d walk into an organisation and ask them what methodologies they use to manage their teams and processes and would be met with “We use agile… we don’t write any specs, we don’t provide estimates, we can’t tell you when we’re going to be done so we’re agile.” I suspect many organisations will misuse the term ‘lean’ in the same way “.. we’re very lean because we follow a few agile practices… they are the same right?”

5. Patterns of agility

Agile ‘patterns’ have always provided value to those who want to adopt agile practices. Scrum (for example) is an example of a pattern of agile, including many practices and rules that should be followed as a whole. Scrum, however, may not always work in all situations. In addition, Scrum doesn’t address a great many set of agile practices that fit well together (such as agile design and build practices, DevOps, etc).

A few years ago, Stephen Forte and I started talking on something called the ‘Agile Buffet’ where organisations would pull in agile practices based on their specific needs. We would always end our lectures by constructing a few ‘agile recipes’ with the audience to demonstrate how this worked.

I think we’re going to see more specific pre-baked agile recipes that will act as guide to customers of different types, providing them with a list of ingredients along with the steps required to mix together agile practices that fit their specific needs and tastes. Heck, if it looks like the prediction isn’t coming true, I may just sit down and write these myself.

6. Renewed focus on specification

I remember the good old days where I worked on a team employing the Rational Unified Process to the extent of its abilities to build a large and complex insurance solution. The specification and elaboration processes were much larger than the implementation effort and much of what we produced (from use cases, to use case diagrams, sequence diagrams, class diagrams, activity diagrams, and every other document and diagram you can think of) weren’t very consumable by anyone we provided them to. At the end of the day if we wanted to validate requirements with users we ended up using wireframes. Developers who were meant to consume the rest of our piles produced specifications never really used anything we produced, solving that problem by coming over and having a conversation about what to build.

For many reasons there has been a backlash against specifications. I know many ‘agilists’ who spit in the face of the word ‘specification’ claiming it’s not agile to create specifications, that it’s wasteful (this may come back to the misunderstanding of agile in general that I keep on observing as well). In reality, this just isn’t true. There needs to be some form of specification created before you start writing code, some way to envision and communicate intent, to validate approach before effort is exerted.

Today we see a great amount of effort being put into wireframing and designer mockups. These are fantastic since, for the most part, these types of specifications are easier to produce than writing code.

Now, don’t get me wrong. I’m not saying that you should all go out and write exhaustive specifications now. What will happen will be a re-inflation of the world of specification used in different ways in agile. Wireframes are great but that may not all be what you need. I’m a big believer of BDD, and even BDD (a highly promoted agile technique) leverages very discrete specifications in the form of Gherkin. Agile doesn’t tell you NOT to produce specifications, but do so for a reason and produce them in a way that is directly consumable by someone or something.

Over the years there have been great strides in ‘specification’ types and tooling and I think these techniques will become more mainstream helping organisations capture/produce/validate requirements even easier, as well as help to generate application components and associated tests even more efficiently. In fact, I believe the tie between ‘specification’ and ‘test’ is the strongest, so look for some fantastic innovation in this area.

7. Git dominance

There is not a lot I’m going to say about git dominance. Git has been growing in significance for years, especially in the realm of enthusiasts and startups. Git hasn’t made very strong crossroads into the enterprise—yet. We’re going to see this change as Git will continue to make large leaps and become an important fixture in both enterprise and lightweight development shops.

In 2012, even Microsoft started to embrace this fact by providing basic Git replication support to its Team Foundation Server product opening the door for merger of client-server and fully distributed source control approaches. We’re going to see much, much more investment around Git in 2013 across the board.