Why should you care about Agile?

Because you care about delivery

Building a sustainable software application is not like constructing a house, a theatre or even a dam designed to hold back millions of tonnes of water. Software is not made of concrete. Things can be changed at any time and the effort and complexity to produce any part of the software whole is often not well known. Contrast that to the well-established housing building methods, 100s of years of structurally proven theatre designs; as well as the huge investment in concrete science, etc. Granted construction projects run over budget/cost all the time, but each component, and each dependency is orders of magnitude better understood than compared with software. In software, we use patterns, open source libraries and established conventions to make our lives easier, but any given team and team member only occasionally builds something the same way more than once or twice. Conventional project management is not suited to the uncertainty, variability and constant priority changes that the software industry is subject to.

If you’re like me and you care about getting real value into the hands of users, then you care about delivery. Delivery in this context is the constant, consistent rate of valuable product being shipped to and used by the customer. This is not delivery to the internal stakeholders, or the managers who might be injected into your process. This is working, production product. Not even “production ready”! I’m talking about working, fully integrated product deployed into the PRODUCTION environment so that end users can realise genuine day to day benefit from your work.

Perhaps you deliver like this already and you just need a framework to track the work. Perhaps you can’t fathom a world like this and you’d like to educate me as to how impossible such a fairy tale is in your world. That’s fine. I’m here for you. I’m on your side. What’s important is that you care; and that’s all I need to get you started. We’ll do this together, using small steps. We can make things better.

The #agileforteams process will accommodate the roller-coaster of software priorities, changing scope, and hard deadlines provided you apply it with discipline and rigour. Agile is not easier. Let me be clear: if you want to deliver with measurable momentum, it’s going to be work. “Waterfall” project management techniques do to some degree enjoy a special luxury: I call it “finger in the air” estimating. The long and the short is this: dates and estimates often have some amount of “guess work” built into to them, to varying degrees. I don’t believe in guess work. I believe in data. If you care about delivery then you should care about data. The popular legalese disclaimer reads “past performance is not a good indicator of future result”. However, when one can be disciplined about the methods of measurement, past performance can be a very strong indicator. More on this later.

Because you care about your team’s morale

There’s nothing worse than coming home from work (or popping out of the home office if you’re lucky enough to be able to work from home) and feeling like you’ve achieved nothing that day. Actually, there is: in my opinion, it’s much worse building something no one cares about. But let’s focus on the shorter time frame. Developers work hard and write code but feel like they’re “achieving nothing” all the time. Often they don’t talk about it, and even more rarely will management talk about it.

But you can’t always change your management team - let’s focus on what you can change. You want a team who’s excited to come to work because they’re excited about what they delivered yesterday. How does a member of your team know they’ve delivered? Because they have a mechanism for tracking real value transitioning from the build team into the hands of end users. Most teams don’t have this. Most KPIs are some distance or vague abstraction from defining real value. If you want a team who’s driven and motivated to work and work hard then you need some way of giving them a scoreboard. The score shouldn’t be in terms of misleading metrics like lines of code or hours worked or even commits pushed (counter point: more and smaller commits are very healthy). The score needs to be value - working production code in the hands of users. Ideally, this is also the features or behaviour that they have asked for too.

A team who can “move the needle” on the collective team score will be truly motivated. If they can move the needle (and move it daily if possible) they will be delighted, engaged and happy to get out of bed in the morning. You can do this for you team! You don’t have to be the “leader” or the manager. A healthy team is a self-organising one and it looks like it’s going to start with you. Look around: do you see anyone else on your team taking the time to “level up”. No? Then it’s you!

Software is a team sport if you buy the logic that there’s more in the whole than the sum of the parts. You may not get credit for taking ownership of your team’s morale and workplace happiness, but it will help you work better. That alone might be worth it.

You care about cost, optimisation and efficiency

Some readers may have a management bent. That’s ok. After all Agile is management! I refused to accept that, even long after my Scrum Master certification. If there’s something to be gained from optimising the machine (clean code, patterns, testability, readability), then there’s arguably more to be gained from optimising the machine that builds the machine - we’re talking here about the agile process. Once you have one, you can add more to the delivery of value through your colleagues, tooling and decision making than simply refactoring a method in code.

A healthy agile process should allow for self inspection, testing and experimentation, change where change is justified and needed, and a level playing field where everyone’s ideas are equal. Cost optimisation is a function of a good starting point, an adaptable process and the courage to make changes. Notice I didn’t say “smart people”? Your team is smart! Let’s just begin and end there. Go in with the assumption that there’s way more value waiting to be unlocked in your team than you’ve ever realised. With that attitude you will find it. Oh and that “good starting point” is just the linear x at the end of the function - it only makes a small difference overall.

“Hey, you didn’t answer my question. I didn’t hear about doubling man-hours, etc, etc” I hear you say? Well no. I’m not going to say that because (while I take particular offence to getting more blood from a stone) it doesn’t matter what technique you want to use - blindly applying it isn’t scientific and results may be misleading, even if they appear good. You need a system to measure optimisation strategies using metrics that matter. You also need a process that hosts these strategies which can weed out the ones that are not performing, no matter how much your management conscience wants to keep them.

You care about building the right thing more than the wrong thing really productively

This is a small extension of the above but it deserves its own soapbox.

I mentioned up above that we’re not here to talk about #leanUX, validating a pipeline/backlog of work, or any of those “higher order” activities. We’re not. But you will never get there if you don’t have an adaptable process. Those goals absolutely depend on a culture of experimentation and data-driven testing.

You care because using the #agileforteams process, you stand to gain:

• A highly scalable/efficient team with little capacity waste and Single Points Of Failure (SPOF).
• Very accurate delivery forecasting (based on real work) with dates as far as many months away within +/- 1 week of actuals.
• Stakeholders/customers in full control of what they take delivery of and when.
• Very (did I mention very?) happy customers/end users.

Sounds too good to be true? Well, here come the details. You judge for yourself.

Questions and Actions

This is where you get involved. I’ll place these Q&A at the end of certain chapters to get you thinking and even participating. If you want the most from this ebook, you’ll give some of these a try.

1. How much do you care about your team? Do you simply want to improve your personal contribution or are you more interested in the collective effort. There is no correct answer. Just think about it and write down some thoughts.
2. When was the last time you overheard some direct feedback from your end users about how delighted they were in the product/project you’ve been building? What did they say? How did this make you feel? If you’ve never experienced this, what do you imagine it would feel like?