Recently I had a brief messenger chat with a former co-worker that they determined they were actually using Scrum-ban instead of Kanban. The timing of this chat coincided when I seemed to be coming across a multitude of discussions about what is/is not in Scrum, what is/is not Kanban and so on.
My initial response was “is what you are doing working?“. Her response was, “yes“.
My response, of course, then was “so why does it matter?”
I do understand the desire to have these processes defined but I’ve never much been a fan of labeling. Being “Agile” isn’t about using Scrum, Kanban, Lean or any other tool/process, it’s about being dedicated to empirical processes that work within the context. I also understand the dangers of ”Agile” being tarnished by misused practices but by and large solving problems and rejecting the status quo are what really matters at the end of the day.
As an example, a few months ago a team member who was recently kicked off the team BY the team decided it was worth his time to prove a point by finding a page in Ken Schwaber’s book that mentions it’s not a rule for the team to stand-up at the daily scrum. My reply was pretty simple in the sense that I never said it was a rule. I explained to the team why it’s a good idea to stand-up and the team decided they wanted to sit, so they now sit. (results of our daily ’sitdown’ here).
Is sitting at the stand-up a Scrum smell? Probably. I don’t care though. The team gets more value out of sitting.
Before I knew what “Agile” was, common sense would dictate that if something isn’t working, find a better way of doing it by trying something new. I believe that’s much more valuable than worrying about what label you put on it.
I'll start out with observations I noted each week since starting this ridiculous journey. I wrote these as I went along. I only edited it for formatting, grammar, spelling, punctuation, etc. You may see an evolution of thoughts and lessons. I'll end with the performance outcome from the first month.WEEK 1
- Don't try to get calories perfect. Expect calories to be approximate. Aim for perfect, be content with +/- 20%.
- It is very hard to get an accurate accounting of calories, let alone an accounting of all them. If you try to be "perfect" about it, it would be very easy to get discouraged and to allow the discouragement to become self-defeating. Keep in mind, it's all data, and we're looking for trends, correlation and causalities. If it could be perfect, this exercise would not have become (or would ever be) necessary.
- Be careful with food labels. The total calories FREQUENTLY doesn't add up from the sum of the parts. Typically, the total on the label is LESS than if you calculate
Calories = Fat[g]*9[cal/g] + Carb[g]*4[cal/g] + Protein[g}*4[cal/g] based on the individual parts.
- Weigh as often as you can (thanks @erwilleke). At one point this week I was down more than 4lbs, but at the prescribed weighing, I was only down 1lb. I know that at the prescribed weigh-in time, I was still carrying a number of days of b/m. Had it not been for the earlier mid-week weigh-ins, I might've been discouraged even knowing that I was heavier than I would have been had I expelled my waste. I must get to "regularity" -- need to drink more of things that aren't dehydrating me.
- Make friends with various nutrition/energy bar supplements. Chosen wisely, they're great for energy, fiber, and a sweet-tooth or dessert. Also, properly selected, they're great to keep the metabolism going between main meals as well as to stave off being too hungry at meals. (You don't want to ever be 'starving' at a meal. bad idea. In case you were wondering, I've learned you want to be eating at least 200-300 calories every 2-3 hours. If you find yourself 'starving', you're better off eating something "bad" (like a small candy-bar or other snack) for 100-200 calories to prevent being ravenous at a meal.)WEEK 2
- Try even less to get the calories perfect. Seriously, it's not going to happen, and it turns out, it's not the point really.
- Good solid healthy meals don't have to have a lot of calories, but you're probably going to have to make them yourself.
Ex: eggs/omelettes for breakfast, without lots (or any) cheese, low-fat wraps, load-up with vegetables.
- Keep salad around A LOT and make your own dressing.
- You can probably walk on a treadmill every day and not hurt yourself. In fact, you'll probably benefit from doing so as your body gets used to it and doesn't stiffen back up. Recent studies are even showing that, for example, 3 intense 10 minute work-outs spread out along a day are probably as good (or better) for you as one 30-minute work out. I haven't tried that approach yet. Not sure I'll get to it.
- Drink a lot. Especially things that don't have much caffeine. Keep water around. Don't let yourself get too thirsty or you'll drink whatever's within reach and that can also end up being garbage for you. Otherwise, you'll (a) think you're hungry, and (b) get 'stopped up' -- if you know what I mean.
- This week included/ended with Thanksgiving weekend and the start of week 3 included a trip to the Raven's game (i.e., Tailgating)
- Weight drop from week 1 returned (mostly) and working it off wasn't working. Very bummed but surprisingly determined nonetheless. Re-thinking my strategy.
- I perceive that my b/m aren't regular and that I may be quartering excess unevacuated waste -- leading to weight gain/plain this week.WEEK 3
- Despite a tailgate and several unaccounted meals all weekend since Thanksgiving, Monday AM weigh-in was more than Sunday but still under the starting weight.
- Dropping target caloric intake to 2000 calories starting Monday had an immediate effect. Started losing 1+#/day immediately.
- Keeping to 2000 cal/day seems easier than 2400 for some reason. Suspect the increased calories further increases appetite. Thinking there's a metabolic tipping point for me somewhere between 2000 and 2400 calories.
- Finding a number of high-ROC (return on calories) meals. Most of which include Amylou's chicken sausages, Morningstar Farms breakfast patties or "Egg Beaters". Filling, satisfying and YUMM!
- Have generally not been counting slow carbs from vegis in my caloric calculations, or skim milk in my coffee. Do count dressing, fatty additives and cream if used.
- When calorie counting is impractical, I'm using the "3 hand plate" rule, aka, the "Fat Loss Plate". I'm also keen to avoid obvious starches when not able to account for calories.
- I honestly don't feel deprived despite several days of significantly low caloric consumption.WEEK 4
- 2000 cal/day FTW! Weight moving nicely in the right direction.
- Tracking calories has made it easy to associate meals, dishes, and portion sizes to their respective caloric impact. Just goes to show you how measures have a benefit beyond what the data tells you, but that you can make associations with measures to other (performance) parameters to help guide decision-making even in the absence of precise data.
- Worry *EVEN LESS* about calories being perfectly counted. Shooting for 80% weekly. With the observations on caloric impact of various dishes, meals, and portion sizes, it's actually becoming easier to worry less about the science and more about observation.
- Caloric impact observations together with tracking the calories have also made it FAR easier to take note of how much food is necessary before being full -- this makes it easier to stop eating when no longer hungry, to allow tempting foods to just sit there, to be satisfied with less than what might otherwise seem like a reasonable portion, and to be more attentive to when I'm truly hungry, and what I'm hungry for. Ex: If I know that a meal made from veggie breakfast patties, sliced veggies and hearty bread is filling, satisfying for H hours and consumes C calories, not only have I learned what a satisfying meal looks like, but also what it does/doesn't have to include in order to be satisfying as well as the calories involved.
- I've gone through the spreadsheet and started (where possible) to calculate daily % of Fat, Carbs, and Protein. NOT EASY to keep to a 40/30/30 balance.The benefit (and importance) of being regular
(I'm talking about process stability what were you thinking about?):
Without it you have no idea WHAT you're capable of. It would have been nearly impossible for me to get any idea whatsoever of my caloric profile without the several weeks of mostly uniform and nearly ideal conditions I'm experiencing in which to collect measures that I can use when things aren't uniform, ideal, or stable.
This point can't be over-emphasized.
Had I been on travel these last 5 weeks, this entire venture would have likely been a frustrating exercise. Without the ability to measure most of my meals, with the ability to pay close attention to my appetite, or to exercise regularly, or have any idea/control over what's in what I eat, I'd NEVER be able to get to a point where I can be comfortable not measuring, not worrying, not bouncing from extreme to extreme -- unknowingly.
With just a few weeks of data I am confident I can enjoy treats and snacks without dumping all my work down the toilet. Does this mean I can wantonly, indiscriminately eat junk all the time? No. There's never a time when anyone can do that and not pay for it some how. But it does mean that I can go to a wine tasting and enjoy wines and cheese and snacks and desserts and not worry about it. Why not? Because by the time I attended the wine tasting, I had weeks of data to train me in how much I need to eat to be satisfied, how much I can eat before over-eating, and how many calories are in certain foods as a function of food type and visual size. And, that doesn't even account for the fact that prior to attending the event, I knew how many calories I'd eaten and how many more calories I could still consume and still be in my target range for best results. In other words, I could operate without the constant data gathering and now use the data I gathered to quantitatively manage my efforts.
Your processes must be clearly understood. You must be able to operate them while accounting for the variables that affect them. Merely measuring results (weight, for example) without the underlying processes is what you're doing when you measure the performance side only and don't know the variables going into that performance.The performance of my bottom (line)
Here's what I said I'd do when I started a month ago, alongside what I actually did...
Planned: I plan to eat no more than 2400 calories/day, up to 6 "meals" or snacks per day.
Actual: I started out at 2400 and dropped to 2000 after 2 weeks. After changing to 2000 calories max, I wasn't as good at eating 6 meals/day because I didn't want to exceed the upper limit. Interestingly, I wasn't as hungry on fewer calories. But 6 meals/day is something I want to do, so I'll be working on it going forward.
Planned: I plan to exercise a minimum of 5 days/week.
Actual: During this reporting period I worked out at least 6 days/week.
Planned: I plan to weigh myself once/week.
Actual: As noted earlier, I'm weighing-in more often.
Planned: I plan to measure my clothes size measurements once/month.
Actual: Did that. Summary below.
In the first sixth of my effort, I've lost about 25% of my goal weight. I don't expect this pace to continue much longer, but it's nice anyway.
I've lost a surprising 0.5" in neck size, and 1"+ in chest, waist, and hips each. Also a surprise was losing over an inch in my thigh. I'm not sure whether that might be a function of where I measured, so I took more specific note of where I measured to make sure I'll measure there again next month.
Overall, I'm very pleased.
See you next month.
What most people (80/20) seem to "know" about CMMI and the SCAMPI appraisal method comes from what people learned and how they used CMM and CMMI in the early adoption phase.
However, instead of innovating and using engineering to create appropriate processes, they just reused old and often poorly-fitting processes and approaches to situations they never dreamed of in the 1980s.
Even people with positive experiences with CMM/CMMI tell us that we challenge what they once believed to be “true” of CMMI … but that they’re relieved because many always felt that what they thought was “true” made little sense.Recommend:
Your people with prior CMM/CMMI experience are probably worse than worthless, they'll probably cause you to fail.
This entry addresses an important tip in those cases where you need to demonstrate a CMMI rating even though you’d otherwise have no intrinsic business reason compelling you to do so.
But first, I admonish organizations doing the compulsory CMMI ratings requirements in the first place. So, if you’re a company being externally compelled to get a rating (which is different from being told “you need to improve!”), you might want to send a link to this finger-wagging to whoever needs to hear it.
However, as such a company being externally compelled to use CMMI (just to get a rating), this tip will make it MUCH easier and more beneficial.
Oh, one more thing…. I don’t mention this in the clip: If you’re such a company, don’t look to hire the cheapest, fastest appraiser/appraisal you can find. Doing that will only make the cost and pain worse. Both, short-term and long-term.NEXT WEEK: Everything you thought you knew about CMMI is wrong.
Starting a CMMI or Agile initiative is a culture-changing endeavor. Don't underestimate the changes you'll undergo.
Both CMMI and Agile often require fundamental shifts in culture that usually results in making <gasp!> changes to how things are in your business!
This in-your-face provocative < 3min video is intended to alert executives interested in either CMMI or Agile (or both) that there are no easy answers as to the question often on their lips: “what does it take to do ____ ?” And, that to do justice to their business, they’ll need to devote some time to understanding even the basic context in which to understand any answers they receive (let alone use) about deciding to move forward with an improvement effort.
After all, if everything were going perfectly now, executives wouldn’t be seeking changes to improve, so when it comes to making improvements, there’s going to have to be change -- so get ready!
(I’m assuming [big time] that moving forward with either CMMI or Agile is to achieve some improvement in something!)
In my next installation, I’ll talk about what to do when you really only need a CMMI ‘level’ and aren’t so much interested in any improvement.
What turned out to be a failed meeting with a far away prospect reinforced lessons I learned a while ago....
About what it takes to be successful in business, with Agile, with CMMI, and about creating a culture of excellence.
Can't wait for the lesson?
Here's the bottom line: the discipline to improve shows up all the time, everywhere and in every action. Failure to respect time, respect what people know, and the experience/expertise of your subordinates are all BIG CLUES that your organization doesn't have the culture or discipline to succeed. Even when you're in the middle of hiring someone to help you get it.
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.