You can, of course read the 12 principles of the Agile alliance; sometimes I find them hard to swallow. I also can’t remember more than 5 things.
Here’s my take:
- Smaller packages of work delivered more frequently
- Subject matter experts working directly with technology builders reduces the risk of waste
And that’s it.
Of course, it isn’t. I can’t say anything succinctly.
Smaller packages of work, delivered more frequently
“smaller” is a relative term, and Agile is a relative concept. The idea is that you try to make and deliver the smallest thing you can. The smallest piece of work you can do independently of other pieces of work. Why do we do that? Well firstly and most importantly is that it seems to work; and works much better than any other approach. Smaller packages of work means that there is less overhead in tracking and staying focussed, less problems of scope creep, shorter meetings and shorter documents.
Also, builders don’t try and solve problems which you aren’t trying to solve, so code can stay lean. People who are smart may start solving other problems that they “know” will come up; in Agile where the problem is evolving then you don’t “know” anything, you are doing the wrong work.
So here’s where some people get lost. They think: “whoah. You should stop the problem from evolving and nail it down before you start to work!” Well that sounds great, but it’s proven not to work in practice.
The problem is evolving for 2 reasons:
- The world is changing and you can’t keep up by doing everything up front, you just can’t.
- People actually don’t know everything about the problem when they start
You might think that it’s the best thing to dive in deeper and deeper until they do understand it all, but you are wrong. Making people wait for easy and urgent parts of the system while you analyse the unimportant but very complex parts of the system means two things:
- You end up with a design that is bloated and complex and heavily clipped to the problem as it is today, it’s not going to evolve to vNext.
- Your company will go bust because you don’t have a system that allows them to track orders or trades or whatever.
“delivered” is also a subjective term. What you “deliver” in your project as scoped, designed, coded and tested might not be what goes live this week. You might have 2 different definitions of “delivered”, with 2 different sizes of a package of work. Really what might be happening there is that there are 2 back to back agile teams, one making features and one rolling them out. Or it might not; see Kanban.
“delivered” also means like really delivered, you have to understand that being Agile doesn’t mean cutting corners. It doesn’t mean doing less design or less testing or less documentation of those things. You just do them in a smaller cycle. It’s not just about being done, it’s about being done done. Which means really cleaning up after you, so when that piece of work has to change and adapt, as it probably will, they aren’t flying blind. The absence of a spec and a BDUF means that you have to back fill as you go.
“more frequently” is also a relative term, and it doesn’t mean faster (see next point). It means that you “ship early”, yes; but you also “ship often”. You have to repeatedly deliver, only the act of actually delivering something means you understand the process of delivery and didn’t just get lucky. If you don’t deliver repeatedly you aren’t removing risk. You have to give yourself a chance to learn from your mistakes. And, repetition makes you automate and automate and automate.
Work that is in the pipeline and not delivered is the same as Amazon having 5 million TVs in the warehouse; Amazon had to pay to get them but they aren’t paid for them while those goods sit there, depreciating in value.
Subject matter experts working directly with technology builders reduces the risk of waste
Really this is where Agile is faster; it isn’t any faster to design and build software incrementally. It isn’t slower either, not really. The real advantages are in the lack of waste. You never build the wrong thing, even if you need to redesign it.
“subject matter experts” are not analysts or testers, though they have to do a bit of both in the micro scale. In the classic waterfall model, you would have subject matter experts (what we sometimes call “the business”) working with analysts who are skilled at analysing things (e.g., MECE, 5 whys, etc) but aren’t software people. The analysts work with architects and testers, and they work with developers… (and no one works with the sysadmins who run it in production, of course J). What we change in Agile is to shorten the supply lines and bring the work suppliers (the business) closer to the consumers of work (the builders). That’s great as there is less confusion and better communication.
It’s harder though because everyone needs to be better at communication, more multi skilled, they need to be “requirements engineers” and not be drawn into too many corner cases, they must be their own best architect, a solid tester and they must cut code as well. Not everyone needs to be a master in them all, but you need awareness and close proximity to someone who can help.
“the risk of waste” is high in a waterfall project. You build too much without checking it works together and in live. What makes Agile work better is the small package of work. There is less waste because you stay focussed on what’s important and that smaller package of work is easier to analyse and easier to code and test correctly.
In technology all decisions are reversible*, it’s just a matter of how fast you can reverse and how much you waste. Rework is essential to Agile, and not something to avoid. Rework isn’t waste, it’s sharpening the saw.
That’s the thing: software work isn’t like building it’s like designing. And if you’ve ever worked with a house architect or a graphic designer you’ll know that you repeat as often as you need to and feel happy that you are getting what you want!
“working directly” means direct, face to face conversations, ideally in the same room. Sitting together doesn’t mean that you get the trust, openness, candour, belief in each other and sense of fun that you need to make an outstanding Agile team. But being together and repeatedly delivering small pieces of work gives that confidence in each other, and its real confidence. Not acquired on a rock-climbing course or a boozy night out, but real trust in each other’s ability.
What goes wrong?
Well nothing’s perfect is it?
Working in the microscale can cause some problems. If you are just starting a project, operating with a team that is unskilled at Agile and there is little to guide you technically, then you will make some wrong turns, for sure. Doing Agile design is a skill, and when you do it for the first time you might get it wrong and design too much or too little. But if you pick a tech and a design that is “normal” and composable, you will probably be able to fix it.
You might not need an overall architecture, though that will help if you are in steady state agile delivery. You might not need an overall “guardian” of the quality, but then again, you might. It depends on the relative pressure for delivery from the business, the overall skills mix of your builders (i.e., their tendency to under- or over-design).
One of the things that can go wrong when the team is new to Agile and the tech/builder team is politically much weaker than the business team is that the business team thinks that this is a licence to do whatever they want and get something for nothing. Separating out tech work into separate stories that never get done is a sign of this. Plus all the normal bad smells of imbalance: project crunches, tech people of low status, blame games, etc. Just like waterfall projects, you will not know that you have a problem until the end and you look back over many cycles with code quality declining and support issues draining the team.
Correcting that balance can’t be done with a process only with communication and the building of trust. But the iterative process gives you a chance to revisit the start of work over and over again, and start fresh.
*as opposed to medicine, where limbs don’t grow back. Let’s also assume that the bad decision doesn’t bankrupt the company.