This piece was a great start. We take a modified Lean/Agile approach. The lean/agile/37 signals approach is all about smaller. Less features. Faster/shorter development cycles. This is definitely the direction we are trying to move. They recommend a Scope Down approach. Less scope, more flexibility. "It's better to make half a product than a half-assed product."
The authors share how they make this happen. They say that each time you say yes to a feature, think of it as adopting a child. And you have to take your baby through a whole chain of event (design, implementation, testing, etc). They recommend saying "No." I like their "Fight Club" reference:
"You should only consider features if they are willing to stand on the porch for three days waiting to be let in."
Part of their lean/agile approach is to "get something real up and running" as quickly as possible.
They recommend against long estimates. "Estimates that stretch into weeks or months aer fantasies." We should be breaking down projects into smaller bites. A 12 week project becomes 12, 1 week projects. Keep dividing problems into smaller and smaller pieces. Stop trying to eat the whole elephant. You have to go one bite at a time.
Quick release cycles. This is something we have been trying to move toward at work. I think we might need to get even more extreme. We are aiming to hit 3 month release cycles. I am wondering if we should go down to 2 weeks, maybe even one week.
There is a section on productivity. No meetings. No interruptions for a set timeframe every day. I am one of those people that WANT this but have a really hard time getting there.
The book talks about not writing Functional Specs. I don't know how realistic this is when you are developing software specifically for customers. The 37signals approach is that they identified a need and built to that very specific need. We have almost the opposite of that. We said "yes". Often. :)
Instead of writing a functional spec they recommend writing a one page story. Again, I can't see this working for us. Our software is complex. (Which goes against 37signals' philosophy). I need a spec. I need a mechanism for the customer to say yes and for us to say yes. We can change, we can adapt. But we need a foundation. Too often, customers, for myriad reasons will say - "that's not what I meant." OK - you signed off on the Spec. You asked for black, we gave you black. Now you want stripes. That's going to cost you money.
Now - to adopt some 37signals philosophy, you shorten the Functional Spec time by shortening the release cycle. So there is a take away here for me. We ran into this issue of the last iteration we ran through. We were very diligent about documentating the tons of requests. The customer had 100 requests. We said, pick 30. One month to code, two weeks for us to QA, two weeks for you to do your user acceptance. Two weeks in there were new priorities. The spec had to be changed. This supports the shorter dev cycle. I am starting to get religion.
"Software development is a constantly shifting, iterative process that involves interaction, snap decisions, and impossible-to-predict issues that crop up along the way. None of this can or should be captured on paper."
There are some really great insights into hiring software engineers too. As a manager, I have always felt that hiring is super critical. I have never hired a software engineer. But I have a good foundation now because of this book.
Embedded Link
Getting Real: The Book by 37signals
Goodbye to bloat. Simple, focused software that does just what you need and nothing you don't
No comments:
Post a Comment