TSSJS2007 - Neal Ford Agile Metrics
Again, I attended this talk for the same reasons as Venkat’s: to gain more breadth in how Agile is talked about and communicated. This talk links to some good resources:
One of the key enablers for being able to gather metrics is its repeatability. Other Benefits of agile: much less time spent on requirements (traditionally up front, and throughout, vs just a little up front and more throughout). Developers spend more time coding, because they are not in endless requirement meetings up front. Vet architectural decisions early in the process. If you create your standard diagram describing the system, you are not going to prove out that system until implementation time, which comes much later. In agile you are proving out the architecture and its maintainability in every iteration.
While its a bad idea you ask people how long is it going to take to do this, you can ask them how complicated a task is relative to a task that they did previously. Business Analysts can put together user stories that place the focus on the user, rather than the system. The developers then consume these stories (which have much less detail than a use case), and then the developers decide on a high-level architecture (stuff that is hard to change later: what language you are using), and then sit down with the business analyst and rate the story cards on a complexity scale. Its either a 2,4,8,16. I’m asking how complicated stories are in relation to one another. You are not trying to slice things by hours or days. The project manager takes this list of numbers and multiplies them by a load factor (size of project, how many meetings you have) with the assumption that its going to be wrong, because we are going to change it as it goes along. Realize that you are going to get your first data point in two weeks, so that after several months you can hone the load factor number to the point where you will be fairly accurate as you go along. Q: the story doesn’t have enough details though A: Its good enough, and I’m not trying to get an exact estimate. Q: but what about technical requirements that influence the story? A: well you can have technical stories because because these are going to make things more complicated, and so they should be factored in.
The load factor is the magic part of all of this, and it may be wrong, this is a skill that the project manager needs to gain over time. Not only are you throwing the dart on the wall, but you are going to tweak it as soon as it makes sense to do so. There is magic in all estimation processes, and most people are asking each developer to apply their own magic. Its a better idea to have one person apply the magic and get better on this, so at least the error is spread evenly. Too keep from poisoning the well they use rock paper scissors at thought works to throw out their estimate, so that people are not influenced by others. YAGNI: you are not going to need it. Try to only do things that are needed to complete the story. It is better to keep related things that you swear you are going to need, on the back burner for when you are going to implement it. Chances are good that what you write now will need to be heavily modified when it comes to it later.
Agile is actually disciplined because it is driven by story cards. The cards have the domain defined completion criteria. You must have Specific completion criteria that reside in the domain, and it must be a hundred percent done to be done. Until its a hundred percent done its zero percent done.
Metrics: most of the metrics books are outdated. The way we write software now changes abruptly: we are writing more complicated things. Problems have gotten harder, although tools and languages have gotten better. Most text book metrics focus on thousand lines of code and other meaningless metrics. For example how do you measure productivity if someone finds something better that removes 20,000 lines of code? You need to validate your measurements continually. Otherwise you are measuring apples and oranges. Agile gives us consistent repeatable steps.
Testing is the best metric you can have. One thing you hear people talk about is trying to compare software to bridge building. The design is not nearly complete enough to be the design. The design in software development is the source code, and the building is pressing the compile button. Our manufacturing process is really cheap. If bridge builders could build little pieces of bridge and test them as they went along it would be a lot easier to build bridges. So over time they use civil engineering to vet their design. The engineering rigor towards software building is testing. Why bother with all of the plans when you can manufacture things so cheaply and just run it to see if it works. The guy who was the heaviest critic of the man who designed concrete reinforced bridges built the tacoma bridge that collapsed. The concrete bridges were proved to be better through testing, mathematics of the day ended up failing: they claimed that the concrete bridges would not hold up, and that the tacoma bridge would. Glenn Vanderburg has a blog entry devoted to this, in fact, Neal borrowed the bridge example from him. Both link to a facinating article written in 1992 on the topic of whether or not Software Design is Engineering, written by Jack W. Reeves.
Microsoft Project is the most abused piece of software ever. People usually create the gant chart and show the completion date. Then the manager says no I need it done sooner, and then they hack together a shorter timeline. We are wishy washy on completion: we make up percentage numbers as we go. And most managers as a result believe that we failed mathematics. Binary completion criteria for all tasks is the key factor of being able to do metrics. This gives you the ability to say to a manager we are 62.3 percent done. This also gives you the ability to say to people who are changing the scope: here is our list of things we are doing, what would you like to remove so that we can do this new thing. You also want tasks that are as atomic as possible. Things that take 5 days are not so good, things that take 2 hours or a day are great, things that take 8 days need to be split up.
Project managers at thoughtworks use spreadsheets and not Project. There was some discussion as to wether or not share Sparky’s spreadsheet. They decided that they would allow you to download Sparky’s spreadsheet, but to remove the formulas. The spreadsheet is the result of many many projects that Sparky has worked on. The first page is the high level overview for managers. The first box is the sanity check question: “Do you have enough development capacity remaining to complete the remaining Priority A cards. “Number of cards through narrative” means that the BA’s have filled in details and have determined what the completion criteria are.
The binary completion gives you a concept of done that does not have the fuzziness of I’m % so far done. Q: who manages this A: the project manager does this. The PM has 3 jobs: 1. keep client and business people out of the way of the developers 2. keep good snacks 3. keep everything going and on track and measure progress, move impediments letting people do their development work instead of emails, meetings, and tech support. Q: how do you handle bugs A: the failed tests get high priority cards for the next iteration.
Code coverage tells you not that things are correct, but rather that your code has been touched. You want to try to not have the users be the first people that are touching the code. You can download slides and examples from Neal’s site, which includes Sparky’s spreadsheet.