Comment: I have given links to Amazon, which has some benefits. There is certainly no obligation to buy from Amazon.
Suggestion: Some of these books are technical (in one area or another) and some are more about people. Mix and match. Consider what you need to learn. Consider what you are most ready to learn. And don't think too much in the sky. Quickly see how much you have really learned by putting your ideas into action.
My younger daughter has her last swim meet of the season tonight. I am excited (and still a bit affected by Father's Day yesterday).
When I talk about Agile & Scrum & Lean, I often refer to Michael Phelps' attitude. Not his attitude in SC, whatever you may think of that. (Not that I begrudge him some relaxation.) But his attitude about swimming. He broke the world record before the Olympics, he broke it in the first heat, again in the second heat, and he intends to break it again in the finals. He is relentless.
We ordinary humans must take the same attitude.
Just about now, your colleagues would be encouraged by seeing you break your own best record.
Just about now, the other teams would be encouraged by seeing your team break its own best record.
So, what do we mean practically?
Well, first, we mean sustainable pace. We mean that we will break records in our new product development work, not by working harder, but by working more creatively. By creating knowledge -- faster, better, with more certainty, and more power.
Second, we will admit that half of what we know is wrong. (Cf TaiichiOhno in "Workplace Management".)
Third, we will double the team's velocity. In 6 months or less.
Doubling velocity (story points done-done in each sprint) usually means we must improve several things:
* a clearer definition of done (or "done, done" if you prefer). Usually we let this be too vague. Vary it must for some stories, but for most SW dev stories it must be very clear and can be consistent. And in my opinion, it must mean "no [known] bugs escape the Sprint". And testing must include at least functional testing.
* we must measure velocity. I still can't believe how many teams I find that don't have some measure of velocity. More on this next time. For now: "Velocity: don't leave home without it."
* we must prioritize the impediments, and keep removing or reducing the top one until velocity is doubled. Hint: We might want to prioritize the impediments by how much the removal/reduction will increase velocity. 25% here, 30% there; pretty soon you're talking a real increase in velocity.
Hint: Improving quality and reducing technical debt are almost always important keys to seriously increased velocity. Not the only keys, but very important.
Who is gonna feel better when the Team doubles velocity (with sustainable pace)? Yes, the Team, perhaps first and most importantly. And customers. And managers. And the widows and orphans who own the company.
Is velocity the only metric in town? Ok, good question, but for another day. Increase velocity now. Show yourself you can do that professionally. Then we talk.
"But, things are so good around here, we can't possibly double velocity." Ummm. My first thought is that your biggest impediment is that people are hiding from the truth. Every place I look, we are using such a small percentage of the potential of people, that doubling the velocity is a task any team can accomplish. Look again, and take Michael Phelps' attitude.
If you really think you can't get any better, declare yourselves the best team in the world, write-up your success, and challenge other teams, anywhere, to beat you. You might just learn a thing or two. And have some serious fun.
I made a post in AgileBusiness (yahoo group). That I thought I would repeat here:
QUOTE I have been asked to start a conversation about BV Engineering. So, here's a start...
What is it?
It is a framework for looking at the delivery of business value. It is called BV Engineering for two reasons. First, instead of hand-waving, we believe that BV Engineering should include qantitative measures (although not be dominated by metrics), and, second, it is called that so that it is approached like other engineering practices in Scrum, as something that is not prescribed, except to say one must always have them, identify them, and improve them. And BV Engineering becomes one of those engineering practices.
Where do we start?
We start with a grossly simplistic franework that says: we have * a box of customers (external and internal typically), * a box of Business (customer facing people, internal groups like legal and compliance, and perhaps others), and * a Team (eg, the Scrum team that will produce or improve one product for those customers).
We also start with an assumption that BV Engineering is a round-trip set of experiments that are continuously trying to prove whether our hypotheses related to BV Engineering are useful. Or, more accurately, it is a feedback loop that continuously shows us how far off our hypotheses are. (And since stuff is happening all the time, we are always at least somewhat off.)
And what do we do next?
Next, based on that simple framework, one does a simple drawing, as with Value Stream Mapping, and describes what BV Engineering is in your specific context.
The flow between all the people is diagrammed. The assumptions and hypotheses are described. The business value model is described. We lay out the current state.
Why?
So that, being visible, we can all see it, and make suggestions, little tests, for improving it. Constantly. That is, so we can continuously move toward a future state.
So, what kinds of things are you including?
Well, anything that helps or hinders us from delivering stellar business value to our customers instantly, at a lower price, solving exactly their problem (or fulfilling their need) with no adverse side-effects. And fulfills all our constraints (eg, a good return to capital, etc, etc).
The approach also works if you make the simplifying assumption that "we only want to make money". As Drucker would say, not the correct basis for doing business, but one that some adhere to.
Back to the things. These things include, or might include: communication (who, what, how, when, etc), gathering requirements, the BV model and its assumptions, frequency of release, feedback from the release, how much we do the telephone game, who needs to understand the customer, the role of tacit and explicit knowledge (about what?), how and where we do knowledge creation, how we balance customer needs with legal/regulatory needs, how we do portfolio management, how we start and kill efforts, the Kano model, prioritizing across multiple customers (or customer sets), priority poker, value stream mapping, personas, use cases, etc, etc, etc.
For example, the use of any one of these things has one or more assumptions tied to it. One hypothesis is that these assumptions have often never been articulated, much less challenged, and even less have they been confirmed as accurate for our specific situation.
Two more observations, each fundamental. As soon as one sees this as a feedback loop (or PDCA cycle) that is trying to prove whether our theories and practices are on target, one immediately asks about the frequency of feedback. And almost always it is not fast enough (GM anyone?). And, second, one then looks at this not as a static model, but as a dynamic model that is always adapting to change. So, one asks "how are we building into our BV Engineering appropriate mechanisms for it to be continuously adjusting in a useful way?"
Lastly, let me add a "personal bias" (which I find empirically true), namely: virtually every team member needs to understand how we do BV Engineering in our specific situation, and where they fit in on the process.
Well, that's a start. Comments or questions? UNQUOTE
Your comments, here or on AgileBusiness, would be welcome.
by Mary Lynn Manns and Linda Rising.
by Taiichi Ohno.
by Frederick Brooks. One of his famous quotes: "How does a project get one year late? One day at a time."
by Mugridge and Cunningham.
by Duvall, Matyas, and Glover.
by Esther Derby and Diana Larsen.
by Kent Beck.
by Michael Feathers.
by Nonaka and Takeuchi.
by Jim Collins.
by Mark Denne and Jane Cleland-Huang.
by Patrick Lencioni.
