I don’t know why this article by Mike Gualtieri infuriates me (http://blogs.forrester.com/mike_gualtieri/11-10-12-agile_software_is_a_cop_out_heres_whats_next). Is it the fact that this guy is an analyst who has never run a software development shop? Is it because all of his information is second and third hand? Is it because he is right in some respects? Of course the rhetorical answer to all these questions is, YES.
Let me start by saying Agile can work, I know this because I have made it work. My experience of 1 is very biased. But the fact that I have a counter example means that Agile works… BUT, and there is a big one, I have never done scrum or XP. I have done agile development for over 5 years but I have never done a prescriptive version of any agile process. And so I have a problem, on one hand I cannot say that agile works because frankly we cherry-picked the best aspects and threw away the others. I can’t say that agile doesn’t work either. So let me describe the process we ran and then my insights on what I think actually works.
1. Everything is the context of the user
It is way too easy to take a technology and map it to the user needs. The flow needs to go other way. The user needs something and you build the product, the architecture, the user interface around making the users ability to solve that problem as effortless as possible. When every conversation you have is in the context of the user the flow moves so much better. Engineers begin thinking of the user more naturally instead of focusing solely on the technology which they are totally immersed into on a day to day basis.
Designing the user experience from the beginning is the point of what we are building. BUT at the end of the day the code accomplishes the goal. There are engineers out there who will shy away from the “hard” stuff because it is hard. My team has constantly heard me say to them “I don’t care if it is hard for you if it makes the users lives easier. We do the hard stuff so they don’t have to.”
You get here by doing a few things:
- Hire designers or developers, testers, documentation people with an eye for user experience design.
- Have detailed and rich conversations about the users problems before you start any project. Understand every nook and cranny of the user and their context and their problems. You will need this later.
- Design the final product based on all the current assumptions… although they will be wrong. Keep it flexible and light.
- Prototype to find the flaws with the design.
- Iterate the design (this is the one anti-waterfall/pro-agile item)
I have not had all these things all the time in my projects and the results have always shown. Every time we include these aspects we see the benefits. I am sure there is more, but a lot of teams don’t even have this much.
2. Conversations and right-sized artifacts
One aspect of agile that is key is collaboration over contracts. In software there are still companies who create contracts between management and the engineering team to deliver the requirements. And you get exactly what you asked for, what the requirements stated. In a 6 month project the amount of requirements is so fast and the interplaying complexity so intense that it takes almost 6 months to nail requirements that will still be wrong in the end. This relates to something called the Cone of Uncertainty. Basically the larger the project the more unknowns and the more uncertain you are of the timeline, quality, and resource requirements. This is true in any project whether you are building a highway across three towns or building a complex piece of software.
So your requirements are wrong, and the bigger the project the more wrong they will be. Your estimated level of effort required to achieve a specific level of quality is wrong and the longer the project is the more wrong it will be. I have lived these facts in every company I have worked in, whether it was my project or someone else’s.
Agile has the most elegant answer to this, although simplified beyond what Mr. Gualtieri is comfortable acknowledging. Working software over comprehensive documentation. Paired with the collaboration over contracts value we have a powerful concept that is best summed up as conversations and right-sized artifacts. This flows directly from #1 too.
When you are with the engineering team and you are discussing the customer in excruciating detail it is important to write that stuff down. Whether you have a formal documentation called an MRD, PRD, User Stories, Scenarios etc. or some other less formal approach, every topic discussed and planned as part of the conversation needs to be written down in some form to remind everyone about what was discussed. This is as much as is necessary because you will talk about it again in even more detail when it comes time to actually implement the item.
At the time that you actually implement the item there is always going to be new information that will change assumptions in the item you originally wrote down. There is a new context. When you got to implement that thing you must discuss the new context and write down the new assumptions so that you are always working against a set of requirements that has the best knowledge baked into it.
Last, in direct opposition to Mr. Gualtieri, working software is a measure of progress. However, that doesn’t mean you are done. Even though the software works it may not be what you wanted. It may not work right even though it matches the careful designs perfectly. It may be flawed in ways you didn’t anticipate. So throw it away and do it again. This happens, you didn’t mess up, it’s part of the creative process. The willingness to throw away working code is as important as getting working code.
3. Regular check-ins
This one is pretty much a follow-on from #2. If you throw requirements over the fence you are going to get exactly what you asked for… but not what you want. It is important for any product owner, product manager, customer, business analyst, etc. to regularly check in and get demos of the software. This is where sprint-boundaries help. It is a mutually agreed upon time where the non-developers get to but their noses in and help steer the project.
This also means that outside of those boundaries you need to leave the team alone. A well put together team can go for a few weeks without direct monitoring. Giving them time to think and put together their best ideas. The middle of that process can show some pretty ugly children of the mind, but the boundaries are when they show off something they are proud of. Like an artist, you want to see the painting when it is done, not when it is being painted. Anyone who has watched Bob Ross has seen him take his paint knife and ruin a painting only to make happy little trees or mountains. But man do you get nervous on that first swipe of the knife. Step back and let the artist do their work. If they are a good team they will give you something beautiful. Just don’t let them do the entire Sistine Chapel without checking in every few weeks.
4. Finish before you start
The worst software projects I have been on are the ones where too much stuff is going on in parallel. It is by far the buggiest and hardest to integrate when so many things that are interrelated are always in flux. A great engineering team will find the right ways to split the project into parallel and serial streams of work. Within each parallel stream there will probably be a mini-serial stream of work. Before a team goes off and starts something knew they should complete the current work as fully as they can based on the requirements. There are different ways you can approach this and the situation will call for the right thing, but there are some successful tricks my teams have used in the past:
- If you are building a broad API for a group of features. Do it in parallel with 1 of those features and finish them together before working on the next feature that uses that API.
- Database changes always come first
- Multi-sprint items need to be cut up to achievable milestones within the sprint boundaries
- Done means: design, code, unit tests, and functional tests are all closed
- Bugs stay flat or go down from sprint to sprint
- Automated tests increase and the pass rate is as close to 100% as possible
This list is not exhaustive and I have other tricks very specific to the projects that I have worked on. To use a hiking analogy, “you always move from water and not to water.” If you have ever been hiking in the Grand Canyon you will understand this. Every time you move from a stable (or at least known) state to another known state then the in between is not so hard to deal with. If the code base is entirely unstable from sprint to sprint you will find that the end of the project is a very hard road with lots of late nights and emergency re-dos of code. Keeping the bug count as small as possible and automated test case pass rate on an increasing trajectory on the boundaries keeps everything in check. When you move from water, you can always go back if you need to.
5. Minimizing the Test-Dev progress delta
This is the hardest thing in all of engineering. There is always a tendency for development to run ahead and put together tons and tons of code and then leave it on the testing team’s doorstep. This approach will and has always failed. To finish something you need it to be fully tested. Without that, the state is frankly unknown and unstable. Having lots and lots of code in that state is bad. So the dev progress should only be slightly ahead of the test process. In Agile they would say it should be totally in sync, but in practice that is never the case. Test and dev have a back and forth and a natural order that falls into line the same way in every team I have been in. TDD and BDD are great goals but I have seen great software come out of teams that have not followed that practice.
When dev and test are separated by entire sprints or entire milestones, that’s when things get squirrely. The closer you can keep the dev and test work together the higher the code quality on a day-to-day basis. You will move much faster with a tested, bug-free code base then you will with a code base that has a ton of features that haven’t been tested.
6. The team doing the process decides the process
The very last item is the kicker. The team is ultimately the judge of the best process to use. In other words the process needs to be tailored to the needs of the business rather than the other way around. When a team is forming for the first time it is good to use a text book version of a process to get going. But continuous improvement determines that it will not be in that state forever. To get better you need to have a process that works for all the teams involved. You need to have a process that works for the management team, the product managers, the engineers, the testers, the documentation team, the support team. The process doesn’t begin or end with engineering.
The process cannot be handed down from on-high. This gets into the same problems as #2. The assumptions will be wrong. You need to analyze the process and the users of the process as much as you would for the users of the product you are building. Mr Gualtieri came up with his PISS paradigm (which he could have made IPSS if he wanted to), but he is wrong, and scrum is wrong, and XP is wrong, and waterfall is wrong, and feature crews are wrong, and my 5 points above are wrong. They are all wrong for anyone but the people who created them. The process that works is the one that works, not the one in the text book.
Here is my advice. Find a process you think would work for your business. Apply it by the letter, then improve it rapidly at first, maybe even throwing it out entirely and starting again with something else. Once you find the one the works, improving it on a regular interval. Be empirical about it. Make improving the process as much a part of your business as building great products.
