I’ve been compiling notes over the years with thoughts and ideas about how I could contribute to the Agile community and try to give back just a small slice compared to what I’ve taken from it.
I decided recently to write a white-paper that describes the experience of the success of a pilot Agile team within a large enterprise organization. What I hope to accomplish by writing this are:
- show that we are “breaking” some of the rules, but are experiencing success
- show the challenges large organizations have adopting Agile
- show the mistakes I made, the ramifications and how we forged ahead
- show that motivation is the most important factor in Agile adoption
How I’m going to structure the white-paper:
- Introduction: who I am, context around why I took the approach I did and context around the organization. The company name, projects and people names will be fictitious but the tactics, results and experiences will be real.
- Iteration by iteration: Starting at iteration zero and moving through our 6 iterations for 1 release I’ll show what our iterations looked like, what activities we did, how we co-ordinated with other groups, team frustrations and successes.
- Summary of what we learned: How the team felt moving from old status quo to new status quo and why they would never go back to “the old way”. This will also include what the team is planning to do for the next release in an attempt to show that despite the success, they recognize they are “not done” implementing Agile and want to get better.
- Reflection: What I learned, what I would differently next time.
- When will it be done? End of December
- How many pages? 10 pages tops, I would like to keep it concise
This is my first white-paper, I’m excited and nervous all at the same time, but this is taking me out of my comfort zone and it is quite challenging. I welcome your input and feedback regarding what you would hope to get from reading this white-paper when it’s finished.
One of my favourite scenes from Tombstone is when Ike Clanton says to Wyatt Earp, “Listen, Mr. Kansas Law Dog. Law don’t go around here. Savvy?” After Wyatt replies that he’s retired, Ike reiterates “Yeah, that’s good, Mr. Law Dog, ’cause law don’t go around here.”
A common theme that has been emerging from the classes I’ve been delivering and conversations I’ve been having are along the lines of “wow, we need to change our culture” or “agile won’t work here because … <insert excuse>“ There seems to be a clear delineation between these 2 camps.
I blogged previously about the importance culture has with an Agile transformation and I make sure that I convey that to anyone I talk to that is new to Agile.
The first statement I usually use to combat this fear, uncertainty and doubt is the fact that there always must be a reason to transform to Agile. Companies aren’t switching for the sake of being cool and hip, well if they are they have bigger problems, but instead they are switching because fundamentally, the way they are working is broken.
Transforming to Agile requires a deep organizational commitment and a fundamental shift in how companies operate and how departments and people interact with each other.
So underneath the skepticism and FUD, what’s the REAL problem? What are people afraid of? Here’s a brief summary of the top 3 excuses for why Agile don’t go ’round here:
1) We can’t have a SINGLE product owner, we need multi-level signoff and too many people are “the go to guy”
2) Agile won’t work here, everybody works on multiple projects at the same time.
3) Management tells us we HAVE TO launch with all these features on this date.
Hmm. So what do we do? Where’s the Agile checklist that allows us to fix these problems? I’ve seen Scrum teams absolutely banging their heads against a wall trying to figure out why their fixed-date, fixed-scope projects either don’t make it or have terrible quality. In this cas,e the ‘rapid de-scoping phase‘ happens in order to make the date but in that instance the damage is already done. The teams inability to say no has rendered their yes useless, mis-trust ensues and the cycle repeats itself.
I’ve had this post brewing for a few weeks and decided to post it after our pilot team’s recent success and after reading Gil Broza’s great post entitled “so you think you’re Agile?”
While our topics do differ, the underlying tone is the same. Organizations needs to understand what being Agile is. They need to look to the manifesto, not to the Nokia Scrum test or a checklist. They need to un-learn what has been instilled through so many years of the command and control approach.
AYE helped me change my approach from saying “here’s what you’re doing wrong and here’s the right things to do” to “what are you concerned about? what are your challenges? how can the knowledge and tools I have solve your problems”
Lately that approach is working much better and I find people who want help are more likely to accept help.
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.