Agile methodologies are just tools

Agile methodologies (XP, Scrum, Kanban, DSDM, Crystal, etc) are for the most part made of really simple tools, so simple in fact that anybody could be told about them and start using them almost immediately

However, in my post agile isn't I said

even if you are doing everything a methodology says you should do doesn't necessarily make you agile.

I said this because the various methodologies are really just a bunch of tools designed to help you with your work, but tools alone won't make you agile.

A comparision

I have a friend who is a master carpenter, his toolbox contains many of the tools I have in my garage, and whilst I can use my tools my results are never as good as his. The reason for this is he has years of experience and a passion for working with wood, not only can he pick the best tool for the task at hand but understands how best to use that tool to get the result he wants. Combine this with his knowledge of wood, techniques for working with wood (joints, cuts, etc) and he will always be better at working with wood than I am.

I could practice with my tools and gain insight into how best to use them and which one to chose but it wouldn't make me a master carpenter, for that I also need the other knowledge my friend has about wood and techniques for working with wood.

Could I learn this? of course but from seeing my friend work and talking to him I can see its not something you learn out of a book, you do it by practice and feedback from more experienced people.

How's this relate to agile then?

As I mentioned before agile methodologies are made up of what are really simple practices and people read books, blogs or attend a 2 day course and belive that they understand how to use these practices.

However, this is no different to me having a bunch of tools in my garage, I know what they are and I have a basic idea of how to use them but I'm not going to get the best results.

This brings me back to my quote from my earlier post, unfortunately a lot of agile implementations out there are done by people who only have the tools they have no passion for it and haven't tried to learn more about not only the practices they follow but agile itself, leading to some of the nightmares you hear about agile in the work place.

It takes time, experience and practice to take these simple tools and understand how best to use them to get the most out of them, you need to spend time listening to other experienced practioners, talking to them, asking questions, etc.

Although my post Agile is... outlines some of the concepts underlying agile, at its heart its about people and tools will only help they won't do the work for you.

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

Trust

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.

Value

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.

Speed

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.

Flow

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.

Summary

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.

Agile is...

My last post covered a lot of things that people associate with agile and how just doing those things don't make you agile, this time I'm going to cover things that good agile implementations tend to display.

Communication

The keystone of all good agile implementations is good communication.

The last post listed meetings & visual work tracking which are are all ways to communicate but what is key is that an agile team doesn't restrict themselves to just these methods, they will communicate whenever they need and not restrict themselves to "set" meetings.

For me agile revolves around communication - communication between members of the team, the team and the larger business, the business and the customer, etc. From communicatin we get

Collaboration

Another key part of a good agile implementation is collaboration, it forms the basis for working in the team and for the team working with the customer/business.

I mentioned capturing user stories as requirements in the last post, these should involve collaboration between the customer/product owner/product champion and the team. The team shouldn't be separate from these discussions it should be a part of them able to provide not only technical insight but frequently a different view on the product as the team has unique domain knowledge from working on the "product".

If there is no collaboration then people tend to fall into silo's & lose the view of the whole product as well as fostering the mindset "it's not my area/problem/issue/job".

Cooperation

Whilst collaboration is about working with other people toward a single goal,cooperation is about working with others towards your own goals. Think about this. In a team everybody is doing their own work to pursue the larger goal that the team is working towards, but an agile team co-operate understanding that everybody needs to complete their work for the team as a whole to succeed.

What does this mean in practice? An example isif one team member finishes their work and can see other people still working on theirs they offer to help them complete existing work before starting anything new.

Control

For a long time developers were told what they had to work on, when they should work on it and often how long it should take them to complete it, they had no influence over what they did or when.

Agile turns this on its head, collaborating with the business the team should be involved in all aspects of the work from generating user stories, prioritising the work, developing, testing, etc.

This apparent reversal of traditional control is done to allow the team to be able to make decisions quickly, rearrange the work based on changing circumstances/priorities to enable them to deliver the work.

Commitment

Work needs to be completed & users using it for it to be of any value to the business, people working in an agile environment understand this.

Don't confuse this with the team committing to complete work in a sprint from the older Scrum guides, this is the business being able to trust the team to complete the work, this doesn't mean working ridiculous hours to finish by the end of an iteration(although the team may decide to do that), it is knowing that when a piece of work is started (barring any changes in priority or direction) the work will be completed and delivered.

Adaption

Agile isn't static, when you first start you may have a framework that you work within but as a team becomes more experienced they use techniques like retrospectives to determine how they can improve what they are doing.

Should you wait till a retrospective to make a change? No. Just like you shouldn't wait until a meeting to talk to other people there is no reason why you can't make changes to the process outside the retrospective.

Summary

People will often point to the agile manifesto and say "that's agile" but it doesn't tell the whole story, other people will point to the agile principles which provide more examples of how an agile team should work but still can't convery the subtleties of working in an agile environment.

Underlying both the manifesto and the principles are the concepts I've outlined above, regardless of if you are practicing an agile methodology or not, you can tell if a team/organisation is agile by observing them and seeing if their culture embodies the concepts listed here.

In my next post I'm going to go into how some of the benefits of being agile, often listed as reasons to go agile, are in fact side-effects of having the right culture and mindset based on these concepts combined with the practices from my last post

Agile isn't...

Meetings

Various agile methodologies outline specific meetings but holding these meetings doesn't make you agile

Capturing requirements as user stories

You aren't writing large requirements documents, you're capturing the details using a form of "As a <user> I want/need <functionality> so that <desired result> This is a good way to focus on functionality that you need for the system (it does have its pitfalls and nuances) but doesn't make you agile

Visually tracking work

Having a board that shows progress of work is really good to help people understand what the team is currently doing and what they've done, similarly charts summarising progress can help people understand trends but doing this doesn't make you agile.

Engineering practice's

Your team practice TDD, pair programming, continuous integration/delivery/deployment, that's awesome and will help you a lot in your day to day work. These practices aren't restricted to agile working so this doesn't make you agile either.

Following an agile methodology

I can hear people say "we do all that, and we have people dedicated to ensuring we follow the process etc" and I would not doubt you but from experience I can still say that even if you are doing everything a methodology says you should do doesn't necessarily make you agile.

So what is agile?

The items listed above all have value in them and I wouldn't suggest you stop if you're doing them already. Just don't think that by doing those you are agile.

In my next post I'll detail what things are common to successful agile implementations that I have seen.