Ah, good old re-work. The thorn in the side of Scrum teams, the impossible mountain to climb for development teams. Re-work is un-avoidable. When people see working software, they get new ideas and might want some changes. Here are some thoughts for handling re-work based on a few scenarios that popped up at work this week.If We Knew Earlier, We Coulda Did Something About it
Situation: During our iteration demos the team I’m working with found that they had improvements and suggestions now that they could ’step back’ and see their work. Other folks who we invite to the demo would have some small ideas or our Product Owner would have some suggestions that were nit-picky, but nonetheless would be better for the user.
Problem: Waiting too long to get feedback.
Solution: I’m happy the team came to this conclusion themselves in the retrospective. One of the team members posed the question that why don’t we show our product owner immediately when we complete the story and not wait for the demo? Side note: I’ve mentioned this to them a few times, but it was great to see them take a problem and apply the learnings on their own.Splitting the Iteration into Work and Re-work Phases
Scenario: There is too much re-work at the end of the iteration so we are going to take our 1 week iterations and shorten them to 3 days so we have 2 days to do re-work.
Problem: too much WIP and lack of communication between team and product owner. (In this scenario the product owner isn’t available full-time to the team and the proxy he assigned can’t always make a decision). There are a few other things happening here as well. The work this team does is non-software and they rely frequently on interacting with people in other departments. They’ll start something, get blocked and move on to something else therefore creating a great deal of waste.
Solution: The team has been struggling with this for a few iterations, I’m not working with them but did have a chat with their Scrum Master since he felt it was a failure on his part. Not so at all. I told him maybe trying to hammer Scrum into their work-style wasn’t the best thing to do. Perhaps a Kanban system would be more effective for them. We talked about what that meant and they’re not ready for that so instead they’ll try communicating with the product owner more often and help the PO understand he needs to be available for the team to fulfill their commitments.Agile/Waterfall Hybrids is What we Did!
This one came up in a training session I was doing. One of the attendees said mixing waterfall and Agile can work because in his experience there was no way to handle re-work in Agile. The solution to this is similar to the first scenario I discussed at the start of this post.
The root of this problem is not getting feedback early enough or the lack of daily communication between the Product Owner and the Team that is required when using an Agile process. A deeper problem was the apparent separation between programmers and testers on the team he was talking about. I wasn’t able to deep-dive into the scenario since it was in the middle of class but I offered some suggestions about why it might be happening.
All of these examples, in my opinion, are some of the main reasons why companies fail with Agile. They interpret “Agile” to mean flexible and let’s just change the rules to make it work for us. While Scrum is a simple, adaptable framework, the fundamentals shouldn’t be changed to accommodate a broken process. This type of dysfunction can lead to mis-trust between the Team and the business and also cause a rift between programmers and testers as they will start to ‘fall back’ into a waterfall mentality.
It’s important that the Scrum Master or Coach help the teams struggling with this to understand what the real underlying issue is and to work through it.
Imagine what would happen if you went to a doctor (or any specialist) who had no experience in your specific condition or situation. Has this every happened to you? It has to my family when I was young. Let me tell you, it wasn’t pleasant. What was frightening was that the “professional” didn’t know that they didn’t have the right experience. What was just as bad was that my family didn’t have the knowledge or experience to know that the person we went to was not qualified.
This is a situation encountered by many organizations when seeking advice and/or appraisal services from a CMMI consultant / appraiser. However, in business, you should at least know enough about your organization and ways of operating to do your homework before picking someone to help you with CMMI.
What you may not have known is that CMMI and the appraisal method are not as clear and obvious as other means of performance evaluation and that you must choose your consulting firm and appraiser very carefully, and among other factors, consider their contextually relevant experience. . . .
The Agile Manifesto is the heart of soul of what it means to be Agile and I often refer back to when talking to colleagues and especially with those that are new to Agile. This post was sparked after a great cross-group meeting that happened yesterday where some information was shared between groups that typically wouldn’t have otherwise collaborated.
I had been asked to present a quick talk on Scrum for a couple of new teams that will be starting up soon, followed by a quick overview of these new projects. The output of this session coupled with what I learned at AYE and through the weekly coach round-table I attend with Michael Sahota, Gerry Kirk and Declan Whelan (special thanks to Michael Spayd for his recent ‘guest appearance’!) gave me some inspiration to write this. I hope it is of value to you.
Client Success over Personal Gain: The Coach isn’t the hero. They are there to help the organization. They need to understand the client and contribute to their success, without worry about accolades or personal gain. This includes the coach fulfilling his duties to the best of his abilities instead of holding back to extend the gig. I like to take the approach that my goal is to work myself out of a job as efficiently as possible because the organization needs to be self-sustaining to succeed. Others will argue that “well, I need to make a living” but I knew the risks when I took this path. If I’m any good I’ll find more work.
Guiding over Dictating: Resist the temptation for the ‘my way or the highway’ approach, especially in organizations that have a more controlling culture. Organizations need to learn and they learn the same way a team learns, through experimentation. A coach needs to help guide them to the answer because the people in the organization are best served to find these answers with the help of a coach.
Objectivity over Subjectivity: The coach needs to remain agnostic in order to avoid making emotional decisions. I do get frustrated when my observation is that the client isn’t listening but that just means I’m doing a poor job of communicating. Remain clearly focused and you will serve the client better.
Adaptation over Doing-What-Worked-Last-Time: Ok, so this one is the same as ‘Responding to Change over Following the Plan” however I mean that organizations are unique. What you were successful with at your last gig won’t necessarily translate into success at your current gig. To me, this one is about understanding the organization’s culture so you can frame your approach. Controlling cultures will require a different approach as opposed to collaborative cultures for example.
I firmly believe it’s the responsibility of any coach to make sure the Agile transition is about the client. Deflect focus from being the expert and help the organization understand that Agile is a tool and it’s only as good as how it’s used by the people using it.
See it here.
Download it here .
P.S. There are other great articles in the issue as well. I'm in great company with an article by my friend, colleague and client, Jeff Dutton. And, don't miss out what's coming next in v1.3 from my buds Mike Philips and Sandy Schrum!
I often find that people new to Agile have a tough time understanding that Agile processes are empirical and there really isn’t a one-size-fits-all model that will work for every organization. Scrum, XP, Crystal, Lean and other Agile methods all have their practices that provide guidance and tools but none of them are going to tell you the recipe for success.
This is one of many reasons why hiring an Agile Coach is a good idea. A good Agile Coach will practice what they preach and use these same methods to help with an Agile transformation. If we are talking the talk, it’s probably a good idea to walk the walk. For starters it shows you’re passionate about Agile and it proves you know the tools and how to apply them. It’s also a great opportunity to lead by example.
There is responsibility and “do’s and don’ts” on the part of the coach and the organization to work together towards an Agile transformation. Below are 4 simple steps with some tips that can serve as a guide for how to approach an Agile transformation. Again, there is no one-size-fits-all approach but there are some basic fundamentals and common sense practices I have found useful that I wanted to share.
Understand: How do you know if you need a hammer for the job if you don’t understand the task in front of you?
- understand why the organization wants/needs to adopt Agile practices
- are they concerned about quality?
- is their business in jeopardy and they fundamentally need to change how they operate?
- are they simple tired of the status quo?
- understand the current state of the organization:
- how the organization is structured?
- where is the support for transforming to Agile?
- what’s the skillset like?
- understand that the Agile transformation is about the organization, not you
- understand that an Agile transformation is more about a culture change than an adoption of processes and tools
- understand that Agile is not a quick fix
- understand the an Agile transformation is costly and time-consuming
- understand that ALL levels of the organization need to be involved
- understand that you will not like some of the answers you get from your coach
Educate: This is important. I find that often people just want the answer. A good coach needs to educate the organization so they can apply that knowledge instead of giving them all the answers.
- teach the 4 values
- teach the 12 principles
- conduct workshops that help the organization understand the meaning behind the values and principles
- make it fun
- Educate them on the use of the tools (both thinking and software tools) you plan to use based on your understanding obtained in step 1
- be open to learning, don’t dismiss the education because “it won’t work here“
- reject the status quo,”look around, it doesn’t need to be this way” – Gerry Weinberg
- challenge and question the education, don’t simply accept everything the coach teaches, challenge those teachings to make them work in your environment.
Execute: Now the hard part. Agile is easy, implementing Agile is very difficult.
- start simple, you should understand how much of a shock the transformation will be, a simple approach may be best
- the organization will not always listen to you. You will serve the organization better if you can remain positive and objective
- collaborate with the team(s) and/or organization instead of giving them all the answers
- learn to ask powerful questions to help them relate the 4 values and principles to daily work
- refer back to the values and principles often, this helps drive the organization to think and apply these values and principles
- start internal user groups, blogs, wikis, get collaboration and discussion happening, spread Agile culture
- remain optimistic, you will be frustrated at times but stick with it
- “embrace uncertainty ” – Jeff Patton
- expect to experience failure, but remember to learn from it
- it might sound crazy, but it just might work. Give it a shot.
Reflect: Use retrospectives extensively, and not just with the team(s). Retrospectives will help the teams with daily ‘in the trenches‘ work and they will help management and executives inspect and adapt on their transformation plan.
- this is a tough one, but be honest with yourself. Are you the right coach for this organization? Do you need help?
- based on organization feedback, add new tools and practices as necessary to support these new learning opportunities
- help the organization learn how to improve in small increments
- try not to get overwhelmed, Agile tends to expose problems very quickly – use reflection to make small, incremental improvements and try to avoid the big-bang solution approach
- be honest with yourself, don’t ignore the problems that surface, attack them
Rinse and repeat often. These 4 steps are cyclical. Reflection leads to a greater understanding which leads to new learning opportunities that will likely require different tactics during execution.
I'm using it to explain that organizations looking for a lead appraiser to work with them towards an appraisal and/or to perform an appraisal ought to think of what we do as they would think of a doctor, not a laborer or vendor.
Do you really want the lowest price doctor?
For that matter, is the highest price doctor necessarily the best in town?
When reaching out and interviewing for a lead appraiser or CMMI consultant, you:
Want the person who is the right person for the job.
Want someone who is qualified (definitely not under-, but preferably not over- either).
Not the lowest bid.
Seriously, whoever you hire for this effort has in their power the ability to make or break your future. They literally have the health and well-being of your organization in their hands. They can put you in the dump just as easily as they can take you to the next level.
They should see themselves that way as well.
Unfortunately I've got too many sad stories of appraisers/consultants who definitely see that they can make or break you, but they don't feel like they personally own the responsibility for what happens to you when they're done.
If it costs too much? So what?
If you get no value? Not their problem.
Didn't see any benefit? Didn't learn anything? Things take longer and cost more and you're not seeing internal efficiencies improve?
YOU must be doing something wrong, not them.
In an AgileCMMI approach, your CMMI consultant and/or lead appraiser would see themselves as and act like a coach, and would put lean processes and business value ahead of anything else. And, an AgileCMMI approach would know that when the processes work, they add value; when they add value people like them and use them; when people like and use them, the next “level” is a big no-brainer-nothing. You get it in your sleep.
Let me know if you want help finding the right lead appraiser or consultant.
What I really enjoy about being part of the Agile community is open communication and willingness my colleagues have to learning and self-improvement.
I’ve been fortunate enough to interact with some wonderfully brilliant people and a keen observation I’ve taken away is how these folks give feedback to fellow colleagues. The flip side is that when it comes to a manager/employee relationship, very few managers I’ve worked with have this unique skill. I’m quite sure there are some great books on how to give effective feedback (actually, please add some to the comments…I’d love to read some) but I’ve been on the receiving side of enough generic “great job!” comments to know what people truly find appreciative when receiving recognition.
While praise has it’s place, there is no substitute to providing concrete examples of WHY you are appreciative of someone else’s efforts. When I give feedback to team members, employees or direct superiors I make sure to provide them with specific examples of why I appreciate them. A recent example was feedback I gave to a co-worker who is not part of the team I’m working with. This person provided support to our team and also willingly participated in a couple of estimation and planning sessions because the team needed his help. I made sure to state my appreciation that, although he wasn’t part of the team, the team experienced success because of his help at key points in project.
Another side effect of being specific is that your feedback will be more honest and the receiver will be more appreciative because they will know you aren’t just blowing smoke.
Your people with prior CMM/CMMI experience are probably worse than worthless, they'll probably cause you to fail.
Because what they (or you) think they (or you) know is probably wrong and the advice you’re getting, the expectations being generated are entirely off base.
It all goes back to the many ways in which CMMI can be done poorly and the few, simple, but hard work ways in which it can be done correctly.
Every time I meet with a new prospect I’m confronted with reams of inaccurate assumptions and assertions about what it will take to implement CMMI and how am I expected to “do all that” and still claim to be “agile”.
My simple answer: I’m not going to do all that. And, you shouldn’t be doing it either.
Seriously, you’ve got to wonder about executives who will force their company into doing stupid things for the sake of a rating instead of doing their homework to learn about CMMI before they head out on an implementation journey.
A recent client didn’t know any better. They hired a consultant and an appraiser to evaluate their work against CMMI and to help them prepare for a SCAMPI appraisal. Unfortunately, they got as far as the appraisal only to realize they weren’t going to get the target Maturity Level. (I won’t get into some of the inappropriate behavior of the firm they hired.)
However, when this client was confronted with:
- Do something stupid, or
- Find a better way to do something smart.
They took option B and found a consultant and an appraiser who understood their context and found how to both be on a disciplined improvement path while also remaining true to their own business.
Fortunately for them, this client had a strong engineering backbone and knew what they did worked and were confident in their processes. Many companies have a while before they can claim that much.Next week:
Picking a Lead Appraiser: "Dammit, Jim! I'm a doctor not a bricklayer."
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.