I attended the Rally webinar about Keys to Successful Release Planning and heard a great comment from the presenter:
“Focus on delivering software, not the plan.”
Think about that for a minute, it’s ok, I’ll wait.
<insert jeopardy music here>
One of the myths of Agile is that Agile teams don’t plan. Agile teams focus on ‘planning‘, not ‘the plan‘, there’s a difference. Let’s face it, the software development industry moves quickly and for the lack of a better phrase it would just be completely nuts to plan out exactly what we will deliver for all of next year. Sure we’ll have a loose plan for what we want to deliver based on what the company strategy is, but are we going to follow that plan into the ground or adjust to new information? Remember, the Manifesto says we value responding to change over following a plan.
So what’s good about a plan? Everybody loves a plan. Plans are what keep people accountable, plans are what make us comfortable, plans help us feel secure. Once you have a plan, you have set expectations.
So what’s not-so-good about a plan? Once you have a plan, change is difficult due to the perceived chaos change introduces. Once expectations are set, traditionally changes aren’t effectively communicated to all those who should know about it. Plans can be used to place blame when things don’t go according to the plan.
At the end of the day we are delivering software, not a plan. In the end when plans change and chaos ensues, the issue isn’t the plan, it’s communication.
Case in point, in our iteration 6 demo one of our stakeholders asked “I thought you were doing XYZ?” Was it the stakeholders fault? Nope. Was it the outdated roadmap the entire company was looking at? Nope, ok, maybe partially. It was a communication problem.
We had failed to effectively communicate to all of our stakeholders the change to the plan. Sure this change happened 3 months ago and sure this particular stakeholder hadn’t come to any previous demo but once this stakeholder had the plan in his hands 3 months ago, his expectation was come hell or high water, we will deliver the plan.
This creates a vicious cycle, especially in organizations that lack trust. If the team doesn’t deliver the plan, the business instinctively responds with more process and more control. Obviously the team can’t be trusted if they can’t deliver on this simple plan we agreed to right? People, especially teams, become deflated, morale sinks and people co-operate less for the fear of the ramifications of the decision to change the plan. Another nasty side-effect is the battles about scope-creep. We become so focused on arguing about what’s in-scope and what’s out-of-scope we lose sight of the fact we’re delivering software.
So how do we get out of this oscillating cycle? First of all, communicate better. Help the business, or folks having difficulties adjusting to Agile, understand why Agile teams plan the way they do. Listen to their concerns about why they want a committed roadmap for the next 3 years. People are often resistant to change but it’s important to not confuse their response with resistance. There is always an underlying reason for why people respond the way they do, keep the communication open and move forward. Of course you won’t always agree, but listening to others concerns is a great place to start.
Today I put myself into a program of health and fitness with the express purpose of "putting my body where my mouth is". For the next 6+ months I plan to track specific health & fitness measures as part of an overall performance objective of increasing my endurance, losing body fat, and gaining better health. Using the values, principles and practices of high capability CMMI, I will demonstrate statistics & quantifiable results.
Making this effort public and committing to report the results by SEPG-Europe 2010 is part of the effort to personally motive myself to stay on track.
I plan to track normal effort for about a month, then to begin looking for patterns, correlations, and perhaps even causality. In particular, I plan to seek processes, baselines, and models that I can begin to experiment with to achieve higher performance and better/faster/long-lasting results. I would like to be able to have specific patterns and models which I can use and manipulate for specific conditions (such as travel, availability of exercise equipment, lack of planning/control over food choices, and other variations).
I would like to be able to further determine the critical sub-factors that I can focus on when I don't have all the ideal conditions for weight and exercise management. For example, what's more important: total calories or calories from some specific source? What's more influential: what I eat or whether I exercise? What should I try to control more: meal frequency or meal size?
If I had to pick a few things that I could easily manage over time, which would they be?
I would like to result in a long-term sustainable program the works for me no matter what my circumstances, and, if/when I can't control all the variables, what *specifically* can I do to get specific results and how long will it take to get back to where I want to be
Using practices from Measurement and Analysis (MA), Project Planning (PP), Project Monitoring and Control (PMC), Process & Product Quality Assurance (PPQA), High Maturity, and others, I will work towards specific process performance objectives in personal health.
Business objectives (Within 6 months from 15 November 2009):
- Reduce body fat at least 40 lbs.
- Increase endurance/intensity at least 20%.
- Reduce waistline to no greater than US size 38
- Maintain or increase total muscle mass.
- Understand the influence/impact of processes, patterns and tools on health.
- Establish a manageable, defined sustainable process for my personal health including:
- how much I need to eat and of what
- how much I should exercise and what types of exercise
- Create a long-term strategy for well-being.
The information I need is:
- Nutrition data (Calories IN)
- What I eat
- Calories from what I eat
- Distribution of calories in terms of fat, carbs, protein and fiber.
- When I eat
- Exercise data (Calories OUT)
- Type of exercise
- When I exercise
- Intensity (specific to exercise)
- Calories burned
- How long I've exercised
- How I feel afterwards
- Weight data
- Date and time of day
- Have I eaten before weighing?
- Have I exercised before weighing?
- Have I relieved b/m before weighing?
- Was I wearing clothes?
- Clothes size data
I plan to eat no more than 2400 calories/day, up to 6 "meals" or snacks per day.
I plan to exercise a minimum of 5 days/week
I plan to weigh myself once/week.
I plan to measure my clothes size measurements once/month.
For years I've been using the image of a fit man as an example of a "model" for health, and I've been saying that despite the fact that he doesn't represent all men in all situations that he can still be an example of what "fitness" can be. I usually joke about how, despite the fact that the man-in-the-picture's waist is probably smaller than my own thigh, I can still pursue a level of fitness that works for me that would appear as fit as the man despite our differences.
The time has come for me to make good on that joke and to pursue fitness in a way that I have never done before, and, I believe, is a way that I must pursue to finally settle the question for myself of "what does a 'fit' me look like?" It's a question I've been after for nearly 40 years. For about the last 10 years I've suspected the answer will be found in a profound exploration of my own personal process performance.
I hope to reach my initial objectives in time to:
1. Reach a steady state condition such that I can report on both the initial drop as well as some aspects of a "maintenance" state.
2. Have something to report by the time the presentation materials are due.
For years I've been using a health analogy to describe process improvement; to describe the differences between a prescription and a description of improvement. With this fitness project, I will demonstrate how a few simple values and concepts can be leveraged into an entire approach using high maturity practices that convert these descriptive concepts into very specific execution of practices that work for me, and can possibly demonstrate both process improvement and high maturity for others.
I have avoided this inevitable and dreaded project for years.