1. Management and Development Process is Important.
Scrum alone does not work. Eventually it will be frequent releases of buggy code. Saw that one before.
Pair programming can't be sold. From my experience many object to it as they are very anti-social. Their programming skills have been honed by spending late nights in front of the computer alone. It's certainly what I remember doing since I was a kid.
What works better is selling the risks of Solo Programming. Joshua's list was more comprehensive. If anyone has anything to add to this, please feel free to comment.
Frog-in-a-well: The developer has a very small view on what is being worked on. There is no one around to rescue the direction of the code to be in line with what is being worked on. The risk of throwing away what you've written and starting over is real and will happen often.
Productivity not as high: Developer is sitting alone. Goes off on a coding tangent (related to above). Or goes over and above of just enough to work. Or reads a blog, gets entrenched in an email thread, etc. No one there to ensure focus is on building the software.
Low code reuse: Without anyone there to suggest that this was already done somewhere else in the code base, a similar solution is coded. Because it was reinvented, it's harder to refactor the duplication.
There are way more.
2. Removing Risks:
A company goes to agile to mitigate risks better. There was more to this, but I think I was busy finding a plug for my dying laptop at the time. I managed to capture the following:
Technical Debt: It is very hard for business to understand technical debt. At one of the companies that Joshua was consulted to introduce Agile at, there was a method that was 28 printed pages long. He taped them together and rolled the method out on the floor of the hotel lobby. He showed us the video of that. If I get it from him, I'll post it on this blog. The use of endless analogies is needed for them to grasp what the developers have to face.
- credit card: Ask the executives how often they make a payment on their credit card. What would happen if they stopped making payment? This is what developers are faced with.
- driving instructions: Joshua wrote really bad driving directions from a patchwork of old English, pig Latin, etc. He asked the execs if they could use those instructions.
3. Business Trumps Process
Should not happen all the time. See above. Business tends to add features in the fashion of a drug pusher: "Just have another feature..." It is important to be a good debt manager and push back on features before the machine grinds to a halt. "Version 5" software is where this happens. By this time, you are only fixing bugs to the product and don't have enough cycles to push out more features and stay competitive. Like having a maxed out credit card.
4. Engage the Entire Organization
Management, Support, Customers and Development must be involved. The concept of a project community is important. It is usually larger than one would expect.
HR is really important as they usually make dire mistakes such as rewarding cowboy coding. HR should be on board as soon as possible.
A major, big project should be chosen to introduce agile on. A one-off project will always be dismissed as a fluke, or didn't have the high standards that the rest of the company works against.
5. Handle Scaling Problems
Joshua's company's sales pitch. They do eLearing for Agile. DRY on the meta level. It was not productive to repeat themselves over and over because the company is too large to get everyone trained within a reasonable amount of time.
6. Fail fast
Tests will do this nicely. The #1 success factor in agile is automated testing. HTTPParser is an OSS project with tests. They are bad tests as changing one line in the production code will make a slew of tests fail. But this has contributors from all walks of life - should be happy that it's fully regression tested.
7. Gather Metrics
How will you know that the agile practices have helped? Five Core Metrics is a book that outlines how to measure the productivity on your project and other indicators. Agile/XP has proven to eliminate 83% of the defects that are found on large projects.
8. Readiness
This was actually the first point. I'm just remembering it now. The company can have the money, the time, etc. But if the db architects group is a rock that won't budge, agile won't get very far. If that does not change, walk away. Joshua's example was one where the db architects group would take 3-4 weeks to consider adding an extra column in a table.
My question at the end was what specifically was important to report regularly to management - at the end of an itteration. Reporting of risks to management was the number one thing.
I know there was 10 points, but in my notes I may have dropped one or two, or mixed them in with the other points. The Agile Vancouver folks say the power point will be available tomorrow. I'll post a link and update then.
2 comments:
Always rated Joshua from Refactoring to Patterns - and it sounds like a good talk too. As I have to present to the executive at my client in January on why they should evaluate Agile, the tips here will be damn useful!
The power point has some excellent metrics for before/after agile implementation.
Post a Comment