Things Change (and so should processes)

Blogger, consultant and author Jonathan Kohl makes the point that the technology environment teams are working in and building for today is massively different to that in which many of the common development processes were defined in.  He encourages teams to be concious and active in their examination of their processes and be prepared and able to adapt them to the reality they find themselves working in today.  

He recently published an article in Better Software magazine titled "Things Change (and So Should Processes)" he gives an example of the use of automated tests for mobile devices:

;A generally accepted agile development practice is the extensive use of automated unit tests. During the past fifteen years, we have seen an absolute explosion in unit testing tools, frameworks, practices, and bodies of knowledge in this space. It’s been exciting to be a part of it. On mobile development frameworks, though, automated unit testing support can be quite weak. That is a cause for concern when we are used to the benefits associated with these tools on web or other older technologies. On mobile devices, state is incredibly important—wireless conditions, the movement and optimization sensors within the devices, human interaction, emotions and perceptions, and even things like weather changes and lighting. It turns out that automated unit tests don’t really address any of those problems. ... So, my mobile developer friends tend to rely far less on automated unit testing and instead supplement it heavily with other quality practices.

He advocates careful application of a variety of different techniques depentant on the needs at the time and suggests that teams be prepared to look outside of the "rules" of their selected process approach.  He says that:

Some of my agile coach friends have almost lost their minds with concern upon seeing that a mobile development team uses few if any unit tests—only to discover that the team uses different tools that better suit the quality criteria their end-users require. The mobile team has most likely started out with a standard development process and toolset, found gaps or a lack of support in certain areas, and adapted the process.

Laurant Bossavit, author of the sceptical look at some of the "ground truths" of software engineering in his book "The Leprechauns of Software Engineering" makes a similar point about lip-service adherence to a process or approach in a recent thread on Google+.  He compares many of the behavours seen in teams today with those which happened after the adoption of OO in many organisations.  He states

"I can hide all day behind a screen with headphones on in any agile process" is the new "I can write procedural code in any OO language"

He goes on to discuss how Agile used to at the forefront of practice and 

Back in the day, Agile was new and edgy and coming across someone interested in Agile, you could be pretty damn sure that they were someone curious, motivated, smart, in one word exceptional. Not necessarily flawless or automatically a great hire for any context, but at least head and shoulders above the crowd.

However today the reality is that

Agile is no longer all that "edgy" and if you were primarily interested in it because it allowed you to meet unusual people, I can totally understand your looking for something else that plays that role.

He is not advocating abandoning things Agile, but rather taking the time and effort to ensure you get the maximum benefit from the approach.  This takes effort and careful thought:

Similarly, just because there are too many false positives - people claiming association with "Agile" despite little real experience or inclination - doesn't mean the label is valueless. It does mean that you should look below surface appearances, and for things that are hard to imitate; costly signals instead of cheap ones

 But by the same token, among the people who most loudly announce their renouncement of Agile, many are inevitably going to be mimics - practicing the ancient evolutionary art of changing their stripe at the opportune moment, an art practiced only by those not in possession of the costly but substantive attributes signaled by the pretty colors.

As Kohl states in the conclusion to his article:

If you have implemented a process and, after initial success, you’ve found quality issues, people falling behind, or that you are constantly late and over budget, then it might be tempting to think that you are the problem. Rather than blame the people, look at the process. It may not be appropriate anymore. Is it helping all the people on your team to create value, or is it now hindering them? Also, remember that we need to create value not only for our customers, project stakeholders, and company owners but also for our teammates and ourselves. If any of those areas aren’t actively creating value, then there is a problem.