Friday 5 June 2015

What does a good agile environment give you?

In my last post I talked about what made a good agile environment and the post before that I mentioned practices that people often mistake for being agile.

When you put the concepts and practices together the result should be an agile environment with everybody aligned towards the same goal


One of the biggest gains that you get in a good agile implementation is the increase in trust between the organisation and the team.

Historically projects have failed and organisations have lost trust in teams to deliver so they then started implementing tighter project management in an attempt to ensure projects succeed, which frequently leads to more project failures.

The trust can be restored with the team increasing communication with the rest of the organisation by being transparent with the work (tracking work on a card board, charts showing progress, meetings, etc) and through collaborating with the rest of the organisation about work being done and the work to be done.

If the team is trusted to deliver the focus moves from when something will be completed to what is to be completed and how soon it is needed.


Frequently work is prioritized based on a vague idea of what the business thinks is best for the product but often without any context of how simple or complicated a feature will be, collaborating with the team can feed in to discussions around the cost of developing that feature versus the benefit the business anticipates it will get from it.

Value itself is a tricky thing to pin down: is it about money, cost, user experience? Recently there have been some posts (notiable this post and this post) discussing value and showing that it is a very nuanced area.

The good thing about this is value will need to be considered and discussed amongst everybody involved across the business so that everybody understands value around the work being done it can help them with making decisions themselves as to priority of the work.


One reason that organisations want to adopt agile is because they are under the impression that it will speed up development, they are then disappointed when following a methodology the work isn’t being done any faster.

The potential increase in speed, and it is only potential, comes about mainly because with better engineering practices, building the features that are of most value and focusing on creating working software the business ends up being able to use/sell the software in days/weeks rather than months/years.

The people aren't actually creating the work any faster than they were before it is just that they are having to do less rework which means the software is available to the end users sooner, and there should be less defects meaning less time needing to be spent on support all of which combines to allow more time to be spent developing the product in the first place.


Good agile implementations don't restrict themselves to looking at the team creating the work, they look at the organisation as a whole and work out everything that is involved in creating a product, how the work flows through the business.

Once you start seeing the team as only part of the overall flow it may become apparent that there are both upstream and downstream activies which are causing problems for the organisation and it is these areas that need to be tackled to improve rather than just focusing on the team.

A side effect of this can be to question the need for estimates, if you have a team that is reliably deliverying work and is only 1 part of a bigger process what value does the business get from estimates from the team? This isn't to say the business isn't going to want estimates but it is understanding the value of that estimate in context to the larger organisation versus the value from the thing they want to create.


Creating an agile environment is hard, you can take a team and implement an agile methodology but that is only a small part of the story. Done right agile will involve a lot of the organisation (if not all of it), it changes the way people in the business look at the work and focuses them on what is being produced and the part everyone has to play in getting that work done.

More than that though it can prompt people to look more deeply into various aspects of running the team/organisation such as value, reward, motivation and learning to name a few.

Hopefully these posts have given you an idea of what agile actually looks like rather than the perception that it is a methodology or just a few meetings, charts and user stories.


  1. "comes about mainly because with better engineering practices"

    What engineering practices? For whatever you list as an engineering practice in terms of agile software development please correlate to an equivalent practice in mechanical engineering, structural engineering, or so forth.

  2. As I am sure you know each of the engineering fields have their own practices which do not necessarily correlate with each other and as such won't have a equivalent practice.

    The engineering practices I am referring to here are in relation to software development, as that is the focus of this blog, which I do not believe would have a specific correlating practices in mechanical, structural engineering etc.

    The normal practices that are linked with agile are mainly from Extreme Programming (XP) some of which are:

    * Testing (unit, integration, UI automation)
    * Test Driven Development
    * Pair Programming
    * Continuous Integration

    A full list can be found here

    I hope this answers your question.

    1. None of those are engineering practices. Those are development practices, there's a gigantic difference.

    2. Whilst I understand where you are coming from I have to disagree, Software Engineering is a known discipline and in a lot of literature these practices in relation to software development are known as engineering practices.

      Have a look at Oxford University site here, similar one at Carnegie Mellon University here, or one of the industry related sites like Ivar Jacobsons SEMAT for some references.

    3. I agree the link to CMU that those are actual engineering practices. However
      I found that link to be almost wholly unrelated to what you state. Architecture Definition & Evaluation which i saw references Parnas (one of the most, if not most important person in modern software yet nearly no one knows) because he is in many ways the father of engineering in software.

      I don't see your "Agile" including Architecture Definition & Architecture Evaluation which are integral to being agile. Having a system that thrives on change and dampens changes from rippling across every single component in the system.

    4. I wouldn't disagree with you about Parnas or the fact the architecture is integral to software development (agile or otherwise), especially to allow changes that can effect the whole system. I also noticed the link to the Oxford University didn't post correctly, have a look here for details on their course.

      This series of articles on agile has specifically not touched on technical aspects it was instead about some underlying concepts that people tend to ignore focusing only on a methodology or practices and wondering why agile hasn't solved all the problems they have.

      For an architecture focus that can work in an agile environment I like Simon Browns "Software architecture for developers if you haven't read it might interest you.