Great article on the idea of personal agility. People on a team need to feel a personal sense of responsibility to their projects. More interestingly, they need a certain amount of emotional intelligence and personal development to be effective leaders. Traditional carrots and sticks as we know only work for some people.
The best performers at my last job were people who had a carrot bigger than the paycheck, e.g. they needed a green card, or people who just loved the thrill of chasing down the solution to the difficult problem, regardless of the impact this problem might be having. Anyone who did not have these characteristics generally failed to get promoted on my last team.
It looked like they only promoted people who worked 60-80+ hours a week, but it's interesting to think about why those people were willing to work those hours on problems that were the result of what I would characterize as management shortcomings, when the majority of the team was not. It is because the majority of the team had no incentive to work on things they knew were dumb, things that had a small impact on customers, or things that were just painful to work on.
In other words, personal agility is not a new way of commanding and controlling. It is a paradigmatic shift where management must lead by example, show and not tell, and instilling a sense of ownership (and developing a consequent sense of leadership). This is not something you can do by brute force, it is, like house music, something you need to feel. "If you don't feel the stirring in your heart after the first few bars of a tango, go find something else to do". (Rough paraphrase from 'La Cafe de los Mastros').
Friday, May 30, 2008
Tuesday, May 27, 2008
Design for Today's Problems, Not Tomorrow's
p. 110 of Extreme Programming.
"The traditional strategy for reducing the cost of software over time is to reduce the probability and cost of rework. XP goes exactly backwards. Rather than reduce the frequency of rework, XP revels in rework...
"The key is that risk is money just as much as time is money. If you put in a design feature today and you use it tomorrow, you win,because you pay less to put it in today.... However... If there is enough uncertainty, the value of the option of waiting is high enough that you would be better off waiting.
"Design isn't free. another aspect of this situation is that when you put more design in today, you increase the overhead of the system. There is more to test, more to understand, more to explain. So every day you don't just pay interest on the money you spent, you also pay a little design tax. With this in mind, the difference in today's investment and tomorrow's investment can be much greater and it is still a good idea to design tomorrow for tomorrow's problems.
"As if this weren't enough, the killer is risk.... You can't just evaluate the cost of something that happens tomorrow. You also have to evaluate the probability of it happening....
"So, the cost of making a design decision today is the cost of making the decision plus the interest we pay on that money plus the inertia it adds to the system [emph. added]. The benefit of making a design decision today is the expected value of the decision being profitably used in the future.
"If the cost of today's decision is high, and the probability of its being right is low, and the probability of knowing a better way tomorrow is high, and the cost of putting in the design tomorrow is low, then we can conclude that we should never make a design decision today if we don't need it today."
Example: From Chapter 3
"Suppose you're programming merrily along and you see that you could add a feature that would cost you $10. you figure the ROI on this feature (its net present value or NPV) is somewhere around $15. So the NPV of adding this feature is $5.
"Suppose you knew in your heart that it wasn't clear at all how much this new feature would be worth -- it was just your guess, not something you really knew was worth $15 to the customer. In fact, you figure that its value to the customer could vary as much as 100% from your estimate. Suppose further that it would still cost you about $10 to add that feature one year from now.
"What would be the value of the strategy of just waiting, of not implementing the feature now? Well, at the usual interest rates of about 5%, the options theory calculator cranks out a value of $7.87.
"The option of waiting is worth more than the value (NPV = $5) of investing now to add the feature. Why? With that much uncertainty, the feature certainly might be much more valuable to the customer, in which case you're no worse off waiting than you would have been by implementing it now. Or it could be worth zilch--in which case you've saved the trouble of a worthless exercise.
"In the jargon of trading, options 'eliminate downside risk'".
"The traditional strategy for reducing the cost of software over time is to reduce the probability and cost of rework. XP goes exactly backwards. Rather than reduce the frequency of rework, XP revels in rework...
"The key is that risk is money just as much as time is money. If you put in a design feature today and you use it tomorrow, you win,because you pay less to put it in today.... However... If there is enough uncertainty, the value of the option of waiting is high enough that you would be better off waiting.
"Design isn't free. another aspect of this situation is that when you put more design in today, you increase the overhead of the system. There is more to test, more to understand, more to explain. So every day you don't just pay interest on the money you spent, you also pay a little design tax. With this in mind, the difference in today's investment and tomorrow's investment can be much greater and it is still a good idea to design tomorrow for tomorrow's problems.
"As if this weren't enough, the killer is risk.... You can't just evaluate the cost of something that happens tomorrow. You also have to evaluate the probability of it happening....
"So, the cost of making a design decision today is the cost of making the decision plus the interest we pay on that money plus the inertia it adds to the system [emph. added]. The benefit of making a design decision today is the expected value of the decision being profitably used in the future.
"If the cost of today's decision is high, and the probability of its being right is low, and the probability of knowing a better way tomorrow is high, and the cost of putting in the design tomorrow is low, then we can conclude that we should never make a design decision today if we don't need it today."
Example: From Chapter 3
"Suppose you're programming merrily along and you see that you could add a feature that would cost you $10. you figure the ROI on this feature (its net present value or NPV) is somewhere around $15. So the NPV of adding this feature is $5.
"Suppose you knew in your heart that it wasn't clear at all how much this new feature would be worth -- it was just your guess, not something you really knew was worth $15 to the customer. In fact, you figure that its value to the customer could vary as much as 100% from your estimate. Suppose further that it would still cost you about $10 to add that feature one year from now.
"What would be the value of the strategy of just waiting, of not implementing the feature now? Well, at the usual interest rates of about 5%, the options theory calculator cranks out a value of $7.87.
"The option of waiting is worth more than the value (NPV = $5) of investing now to add the feature. Why? With that much uncertainty, the feature certainly might be much more valuable to the customer, in which case you're no worse off waiting than you would have been by implementing it now. Or it could be worth zilch--in which case you've saved the trouble of a worthless exercise.
"In the jargon of trading, options 'eliminate downside risk'".
Plan for priorities, not development
From Extreme Programming Explained: "Planning for priorities vs. planning for development -- Ber aware of the purposes of planning. Planning so the customer can establish priorities needs much less detail to be valuable than planning for implementation, where you need specific test cases."
Thursday, May 22, 2008
Simple Story Template
Great post on a simple story template from Mike Cohn. "As a , I want so that ". Simple constraint.
Saturday, May 17, 2008
Scrum requires course correction at every turn
Scrum is a process of correction. You don't just start doing it and then everything just magically works. The first Sprint will have failures, processes that didn't work, procedure that wasn't followed, ideas that didn't sink in. At the end of the Sprint you review and course correct. Individuals on the team constantly strive to hold up their end of the Scrum contract, while the whole teams looks for ways to change, adapt, evolve, and innovate. It's just like sailing, there's constant course correction that goes from coarse to fine as you get closer to port.
Scrum requires teams
In order for teams to manage themselves, they need to be dependent on one another for direction. They can not look to the ScrumMaster or Product Owner for direction or orders. The team uses its abilities ranging from subject matter expertise to best gut instincts to make its own decisions. It is very much like a sports team where everybody has a role, but the team wins games as a team, not as individuals. In Hockey, you get the same amount of points for an assist as you do for scoring a goal and it is the same in work.
The reason Scrum and stand-ups never worked at my old job was because "team" members were pitted against one another. It was a Lord of the Flies, survival of the fittest, where progress was always reported to some kind of boss man. No one in the group ever had a stake in the success or failure of the work other team members were doing. It was much more like a World Rally Cross event, where team members all drove Subarus but were conducting their own race, competing with each other to win each stage of the rally. It was awful.
The reason Scrum and stand-ups never worked at my old job was because "team" members were pitted against one another. It was a Lord of the Flies, survival of the fittest, where progress was always reported to some kind of boss man. No one in the group ever had a stake in the success or failure of the work other team members were doing. It was much more like a World Rally Cross event, where team members all drove Subarus but were conducting their own race, competing with each other to win each stage of the rally. It was awful.
Why is this here?
This is the question we must always ask ourselves - why am I doing this now, why is this artifact here, etc? It's more efficient to spend some time to analyze what the next important task in our project is and define the point on the horizon towards which all activity and thought will converge for a given time-limited iteration will converge. This is the freakin management, development, and creative zeitgeist of the late 20th century. Agile development, Scrum, "Getthing Things Done", the E-Myth, it's all saying the same thing: get out of your own way and focus. Use the power of disciplinary thinking to your advantage - it is effective.
Story Driven Development
Effective thinking about complex problems means bracketing off. SDD is one way of doing that.
Scaling RoR when you're a Java developer
So I'm coming into a new situation and I can't afford to make dumb decisions based on my own experience and bias. The company has made a large and profitable investment in doing smallish websites using RoR. Problem: maintaining 50+ individually deployed websites (regardless of tech stack) is a drag, so I'm looking for ways to consolidate onto a single platform that can host multiple customer sites.
My hunch as I go into what a former co-worker described as "hardware is expensive-land" is that RoR scales via a "throw money at the train" algorithm. I'd like to be able to scale out layer by layer. Blah blah blah the point is, I am a java developer and there are more well-known patterns for scaling out large java web apps then there are for ruby. At a small company we need proven solutions that a) work and b) aren't too hard to do. The possible trajectories and migration paths at this time I see are:
Grails means I can move to an all Java platform using a very RoR-like idiom that will make life easier for the developers. Groovy 1.6 looks to have the performance problems of Groovy in the bag. It uses Hibernate, the one technology I feel like I have some strong knowledge of, strong intermediate if I were to use skier analogies.
Grails/Groovy books
Definitive Guide to Grails, Second Edition
Groovy Recipes
My hunch as I go into what a former co-worker described as "hardware is expensive-land" is that RoR scales via a "throw money at the train" algorithm. I'd like to be able to scale out layer by layer. Blah blah blah the point is, I am a java developer and there are more well-known patterns for scaling out large java web apps then there are for ruby. At a small company we need proven solutions that a) work and b) aren't too hard to do. The possible trajectories and migration paths at this time I see are:
- JRuby
- Grails
Grails means I can move to an all Java platform using a very RoR-like idiom that will make life easier for the developers. Groovy 1.6 looks to have the performance problems of Groovy in the bag. It uses Hibernate, the one technology I feel like I have some strong knowledge of, strong intermediate if I were to use skier analogies.
Grails/Groovy books
Definitive Guide to Grails, Second Edition
Groovy Recipes
Operations is Job Number 1
Ironic given how much I hated dealing with ops at my last job, since that's all we did, but as I look to forge new ground I need to take the good part of ops with me.
Subscribe to:
Posts (Atom)