Leanpub: Publish Early, Publish Often

What is Agile?

Agile in its most general form, should start with the Agile Manifesto. This is essentially a bunch of clever folks pooling their knowledge and experience into some concise insights by which we can test our agile process over time.

The Agile Manifesto home page could be summarised like this:

A	Is more important than	B
Individuals and interactions	>	processes and tools
Working software	>	comprehensive documentation
Customer collaboration	>	contract negotiation
Responding to change	>	following a plan

This is to say that for each row of this table, items at both ends of the continuum are important. The emphasis is that the items on the left/A are more important than the right/B.

Take for instance this whole ebook and the particular #agileforteams recipe that I’m trying to impart to you - it’s a process. But as you’ll soon see, this process is only made possible by the humans and their human-centric interactions which I will detail. This process I’m about to teach you is very valuable, but the people come first. Remember that.

Now is a good time to have a quick read over the Principles behind the Agile Manifesto. Don’t over analyse it right now. Just have a quick think and how it might relate to the above sections. Those principles will become clearer as we move on. Feel free to come back at any time and revisit them as I unpack more of the #agileforteams recipe.

Agile is open ended, so you need guidance

As you can see, the Agile Manifesto is not particularly prescriptive. It’s open ended and allows for a variety of implementations and only attempts to guide by way of priorities. This also reinforces the fact that agile itself should also be agile, in that your agile process should be adaptable and change over time.

Many don’t know where to get started with agile or find the body of knowledge so vast that the perceived effort is too great. I will detail a flavour of agile which I believe is small enough to learn by doing in the space of weeks. This is something you actually need to practise to learn, like a musical instrument. It’s not a theory activity. It’s a doing activity.

The answer is always: It depends.

Most of the #agileforteams flavour is guidance and goals. This means what I’m going to prescribe or suggest will contain patterns, actions and implementations but you must still apply your judgement as to when something I’m suggesting won’t work for you. Many of these ideas will pay off very quickly. Some might eventually work, but just not right now, or may never work. I don’t know your context so I can’t say. So how does one make such a determination?

Let me teach you a lesson in pragmatic decision making when you want to add something. It might be a line of code, or a new feature or a new element to your process. Test as much as you can with these easy steps:

How-To: To add or not to add

What do I want to add?
Firstly, make sure that you can articulate the item clearly and succinctly.
What value does it bring?
Measure value in terms of tangible gains in the hands of the user/business, reduced complexity for the build team, less effort, or opportunity costs like less waste, or even qualitative benefits like increased morale, more fun, more smiling humans.
What does it cost?
Use the above suggestions but come up with some measure of the cost: complexity, effort, double-handling, increased maintenance, etc. Notice I didn’t include things like time or money here - these are dubious at best and estimating these values is often not a strength of a development team member.
What is the Net Return (value less the cost)?
The value and costs may not be in equivalent terms but it doesn’t matter too much. Pull in a team mate or two and you’ll soon find folks can rationalise comparing these things together. There will be a net gain, net loss or net zero balance at the end of this discussion. Time box yourself to 2 mins of discussion to force an answer effectively.
If a net loss then drop it and move on. Send an email or create (and close) a quick task so that context is preserved for the future.
If a net zero then try to find a reason to drop it. Everything has some intrinsic overhead that you can’t possibly forecast up front. Always try to avoid adding more things if there isn’t a substantial upside.
If a net gain, then consider if it’s substantially valuable. If the group agrees then proceed but always keep in mind that you want to minimise waste. Always try to remember or simply ask out loud “Are we creating or minimising waste here?” Your team members will know what to do.

I encourage you to test the #agileforteams process against the above as you introduce it to your team.

Process first, Tooling second

The first line from the Agile Manifesto reads:

Individuals and interactions over processes and tools

I’ve come to find that of processes and tools, process is far more important than tooling.

Never select a tool to drive your process. Select or create a process first and then try to find tools which support it. Tools here may not be software tools, they could be paper based, or a mental activity or some kind of game the team plays in order to, for example, resolve disputes or tie-breaking scenarios. Tools often have a point of view and by using a tool, whether you realise it or want to, you do to some degree adopt part of that point of view. It’s best to get your point of view (about your process) straight before selecting one from elsewhere. This will give you clarity and help you make decisions.

When it comes to an agile process, the primary tool for tracking work is pretty important. As already highlighted, the human components are more important, yet the goal with a tool should be to get as much intersection with your process as possible. The balance of that intersection is pain, frustration and waste. These usually manifest in the form of complicated UX which you don’t agree with, get value from or need. It could also be something you want to do, but the tool makes it substantially harder. Many software tools are flexible to some degree. If you can disable a component or feature that you don’t need and the UX becomes better then that might be an acceptable compromise.

So remember to apply the How-To: To add or not to add steps above when selecting tooling - it’s all going to cost you something. Make sure there is a substantial net gain. In particular with tools which automate a large proportion of your agile process, be sure to select something that’s as close to 1:1 with your own process: Process first, Tooling second.

Questions and Actions

When have you found yourself working in a team with a good process for “getting things done?” What did that look like? What were the important elements, big or small, which made that work so well?
How do you or your team make decisions currently when you want to add something new? Is it even a team discussion or do folks just do their own thing and the rest are informed next time they git pull? What are the pros and cons of this current workflow?
How do you react when you are challenged on your idea? Are you simply never challenged? If so why? Or is this something you avoid, or do you simply relent when confronted? What would you like your response to be? Give this one time. You might need to think about it for a while. Write down your thoughts for your own reference later.