Have you ever been so focused on something that the rest of the world seemed to disappear for a while?  This can be great under certain circumstances, but in other cases it can be extremely harmful.  When someone focuses on a target and doesn’t see anything but the target we call it “target fixation.”  This can have dire negative effects!  For example, a fighter pilot can become so fixated on a target that they forget to avoid the target and run right into it.  The same can happen as we go through a curve in a moving vehicle.

Unfortunately, a variation of this can also occur to agile teams!  When it starts happening to agile teams it can be very difficult to detect and correct because everyone thinks they are doing the right thing.  It isn’t until much later when most teams finally determine this was the problem.Let me start by giving a few things I think happen when agile teams are too fixated on the target:

1. It becomes vital to “hit the date” or “hit the story point goal” or whatever other goal is laid out.  While this is not inherently bad, when combined with some of the other items below it may be indicative of a problem.
2. The team starts to cut corners on quality in order to hit the goal.  This is done subconciously in most cases.  Teams simply write fewer and fewer tests.  Especially automated tests.
3. Risks and impediments are no longer raised in meetings.  After all, dealing with them may cause the team to miss the goal.
4. Team members work more overtime hours – all in the interest of getting to the goal “just this once.”  If it happens more than once it is time to take notice.
5. Team members start to silo rather than collaborate and communicate openly.  “If I can just stay heads down I can finish this” becomes a pervasive attitude.
6. The team starts to think about dropping the daily stand-up meeting so they have more time to reach the goal.
7. Retrospectives turn into blamestorming sessions.
8. The team starts to miss obvious problems until it is too late in the iteration to do anything about them.

If your team is starting to suffer from more than a couple of these items you should take a step back and see if the goal has become more important than doing the right thing.  I tell my classes “Do the right thing and trust that the right things will happen as a result.”  Starting to do the wrong thing will not magically make the right results appear – except as a mirage.  Sacrificing something good will always lead to an issue further downstream.  Don’t fall into the trap of thinking you can get away with it!

If a team is starting to overly focus on “the goal” to the detriment of doing the right thing then someone needs to step up and say it!  This is where the Scrum value of having courage comes into play.  If someone doesn’t have the courage to stand up and say it is broken then nothing will ever get fixed.  Teams can spin in this cycle for a long time if no one notices the problem.  On occasion a team in this mode will make all of their iteration commitments along the way and then have massive rework to do at the end.  No one ever traces it back to making the goal more important than doing the right thing.

Focus on doing the right thing, inspecting the results and adapting.  This is the only way to improve and reach real goals in realistic timeframes.  Some good reference blog entries to read would be:

• New to agile? Lean principles can help
• Agile antipatterns: Agile burn-down chart roundup post
• New to agile? Learn how to split stories
• New to agile? Remember the power of automation
• New to agile? Keep it very simple
• Agile antipattern: Working overtime

Hopefully your team isn’t overly fixated on the target, but if they are, get it fixed ASAP!

Until next time I’ll be Making Agile a Reality® by pointing out to teams when they are too concerned about the wrong things (which all too often seem like the right things)!

Related posts:

1. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
2. Agile antipattern: But the development lead said it would take way less time than that I’d be rich if I had a nickel for every time I’ve heard...
3. Agile antipattern: Treating symptoms not causes Agile teams often get to a point where they have a number...

This is a companion post to last year’s “I’m a Certified Scrum Coach (CSC) – so what?” post.  In that post I spoke about the advantage of using Certified Scrum Coaches over non-certified coaches for agile or Scrum training.  I also wrote a post called “Agile Ponderings: Certification – useful or not?” where I explored what were then the current certifications available from the Scrum Alliance.  In that one I wrote that I was probably going to pursue becoming a Certified Scrum Trainer (CST) but I had some misgivings about it because of the cost and also the way the application process worked.  Apparently other people had problems with the process as well, AND the Scrum Alliance listened to the complaints.  A beta process was created and I was asked to be one of the first five applicants to use the new process.  I’m writing this blog entry to detail my experiences with the new process, but also to make people aware of how using a Certified Scrum Trainer could help their organization achieve better results.

I want to start with the process of becoming a Certified Scrum Trainer (and I’ll shorten this to CST from here on because I’m tired of typing all those words).  For the past couple of years the process required applicants to have achieved the Certified Scrum Practitioner (since renamed to Certified Scrum Professional) or CSP designation.  In fact they had to be a CSP for at least one year before applying.  Once you had that in hand you could apply by filling out an application form which asked a bunch of questions about your experience and your involvement in the Agile/Scrum community.  You also had to submit your training materials, at least 2 student references and at least one co-training reference (someone you taught a class with).  Once you did all of this and paid the $100 application fee your application basically went into a black hole.  That’s where the fun started

I’ve been told applications were reviewed by a few current CSTs and they gave a yes/no vote.  If they voted to accept you then you were accepted.  If they voted no, then sorry, try again next time.  This process ran approximately twice per year, so next time would be at least 6 months away in most cases.  In my case I applied in September of 2009 and was… drum roll please… turned down in October 2009.  I’ve heard that only 4 out of approximately 30 applications were accepted during that round.  I felt my experience and success level were appropriate to the certification and asked for clarification of why I was rejected.  I received a lot of correspondence, but the bottom line was I wasn’t accepted.

Then came the Orlando Scrum Gathering where I happened to run into Jim Cundiff who was restarting his role as Managing Director of the Scrum Alliance.  He spoke to a number of us prior to a board meeting where the topic of the CST application process was an agenda item.  The result of the board meeting was the creation of a group tasked with coming up with a new process for CST applications and a few individuals, including me, who were named as the initial beta testers for the process.

The new process was rolled out in April, 2010 and is a LOT better than the old process.  The new process actually requires a CST applicant to PROVE downstream success of their training through endorsements of at least 5 students, and more importantly, at least 3 different organizations!  Then it went a step further and requires at least 5 sponsors from within the CST/CSC community.  In other words you have to have student success, organizational success AND you have to convince at least 5 potential peers of your abilities.

It took me a few weeks to get all of the necessary documents in place, but on April 21 I submitted my CST application.  Two weeks later there were no objections so I was accepted as a CST (the normal 30 day period for objections was reduced to 2 weeks for the beta process).  I feel honored to have been accepted and also humbled by the great things people wrote about me for my application.  I hope to live up to it all!

Now, why is all of this background important?  Simple – just like a Certified Scrum Coach has obtained that status through experience which can help organizations, a CST has some proven abilities as well.  I’ve been asked by others how to know if a trainer is any good.  Net Objectives has a list of questions to ask someone when looking for CSM training.  I don’t like some of their questions because of some assumptions they have made (full disclosure: between September 2006 and April 2008 I worked for Net Objectives so I don’t dislike them, I simply don’t always agree with them).  I also prefer to ask questions about a trainer in general, not just a CSM course!  I’d ask the following questions:

1. Does the person have significant experience in training organizations of all sizes and types?
2. Does the person have references for successful training engagements (at lesat 3)?
3. Does the person have access to other trainers and coaches to help them get answers to difficult questions/problems?
4. Does the person have experience training the type of course you are trying to get? For example, do they do team based training, role based training, etc?
5. Does the person lecture or do they facilitate a meaningful training workshop?

You can ask all of those questions, or you can ask just one: Are you a Certified Scrum Trainer?

You can get away with this single question because a CST will have positive and acceptable answers to all 5 of those questions (and MANY more)!  Once you know you have a CST, then start digging deeper around any specific areas where you have concerns.  CSTs are excellent trainers, but not all have the same experiences.  Some will fit your situation better than others so be sure to ask questions.  On the other hand, as question 3 makes reference to, all CSTs have access to the entire CST/CSC community to help them out.  That is access to well over 100 of the brightest trainers and coaches in the world.  There is almost nothing which will stump that group!

Until next time I’ll be Making Agile a Reality® by starting to set up some Certified ScrumMaster courses.  My first one is already listed and is a unique co-facilitation with Roger Brown in San Diego.  Sign up before May 26 and get the early bird discount!

Related posts:

1. I’m a Certified Scrum Coach (CSC) – so what? I’ve asked myself that question more than once in the 5 or...
2. Agile Ponderings: Certification – useful or not? I’ve had to do a lot of thinking about certification recently. Why?...
3. Orlando Scrum Gathering – I’m going to be a doctor soon! In about 5 minutes I’m going to play the role of being...

Is the bug to the left a large bug or a small bug?  It looks HUGE to me!  Well, in reality it is probably between .5 and .75 inches long.  Not really a very big bug at all.  Why do we care? Because trying to size the fixing of software “bugs” is at least as hard as figuring out how big this bug is!

When I teach an Agile or Scrum course someone will almost always ask a question like “How do you handle bug fixes in iterations or sprints?”  When I ask “How do you want to handle them?” we get into a pretty interesting discussion.  Most people say something similar to “We should prioritize them with the user stories, size them like we do user stories and then see what fits into each iteration.”  I usually smile and ask any developers if they know ahead of time how long it will take to fix a defect.  They ALWAYS say “Sometimes.”  And THAT is the problem!

How can you actually determine the size of fixing something which is broken in an unknown way?  I tell people in my classes I only know two sizes for defect fixes: 1) Trivial because I already know what’s broken and how to fix it, or 2) Infinite because I have no idea what’s broken or how to fix it!  If those are the only two sizes available to us how can we possibly put them into iterations effectively?

I have found one effective solution to be the use of Kanban techniques for defect fixing.  I don’t want to get into what Kanban is or isn’t and when it should or shouldn’t be used, so I’ll just lay out what I have seen be effective for a number of teams:

1. Prioritize the defect list.  This is NOT done in the context of user stories, but separately.  The list is prioritized however the Product Owner says it should be prioritized.
2. The team and Product Owner decide on how much effort (time) should be used each iteration to work on defects.  Hopefully this is not a large amount, but it might be for teams which have large numbers of defects in a legacy system.
3. The team determines when the defect fixing time occurs and how they do it. Most effective is to put a gate or two in place on the defects.  For example, gate 1 may say the developer needs to know within 2 hours if the defect is going to take more than a day to fix.  If so, then put it off until a discussion can take place with the Product Owner.  Gate 2 may be after a day if the defect is not fixed perhaps another discussion needs to take place.  However the gates are set up (if they are)  the defects are worked in priority order.
4. Limit the number of bug fixes being worked at one time to a very small number.  If you don’t do this you will have each developer working on at least one defect and run the serious risk of none of them getting fixed before the iteration or sprint ends!

This 3 step approach allows the team to work on defects in priority order while allowing a set amount of time to be spent on the defects.  The amount of time spent can be changed as needed to address the business needs of the organization at any point in time.

The downside of this is no one can tell a stakeholder something like “that bug will be fixed by date X” or “we’ll knock out X bugs this iteration.”  Saying anything like that is a lie anyway, so this shouldn’t be a big issue.  I say these statements are lies under the assumption the defects are non-trivial.

How else have you managed a defect backlog that has been effective?  I’d love to have more proven techniques for people to experiment with!

Until next time my clients will be Making Agile a Reality® by using sizing only when appropriate!

Related posts:

1. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
2. Testing to find defects is waste Have you ever heard someone say that testing to find defects is...
3. Agile antipattern: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...

What’s wrong with the user story on the card?  It seems to have everything we need: a) short title, b) a size (in this case 2), and c) a well-written story using the standard “As a … I want … so that …” format.  So what’s wrong? Nothing!  Well, almost nothing.  The user story card is a great STARTING POINT, but it is not sufficient by itself.

In coaching Agile and Scrum teams I see many of them starting out with the assumption that the user story card contains all the information they need in order to create a high quality piece of software.  Forgive me for being harsh, but how stupid is that?  Assuming a single sentence can fully describe something which might take a few days to analyze, design, code and test seems pretty ambitious.  No, let me take that back.  It’s more than pretty ambitious, it is just not possible. So I ask again, what’s wrong with this story card?

And again I’ll answer that there is nothing wrong with it, but it is a STARTING POINT.  Many people are familiar with the phrase “INVEST in good user stories” which is an easy way to remember to use the INVEST acronym for guidance when creating user stories.  I wrote a blog entry about that titled “New to agile? INVEST in good user stories“  Web searches lead people to that blog entry many times every day.  But it isn’t sufficient!  If you read agile literature for any period of time you will eventually see the phrase “A user story is an invitation to a conversation.”  This is vitally important to success!  A conversation allows more description than a single sentence.  It can clarify many aspects of the user story.  Taking this a step further we also need to be able to confirm the user story is completed.

Taking all of this together we end up with the 3 C’s of good user stories: Card, Conversation, Confirmation.  Ron Jeffries wrote about this all the way back in 2001 and his advice is still good today.  Agile and Scrum teams need to remember the card is the starting point.  It leads to a conversation where more specifics are given and negotiation (the N in INVEST) can occur.  All of that leads to confirmation in the form of tests (the T in INVEST).  A good story card will likely end up with a back side covered with results of the conversation(s) and confirmation tests.

Next time you see a user story card don’t ask yourself if you need to have a conversation about it.  Instead just assume you need to have a conversation and have it!  Go to the Product Owner or customer or customer proxy and ask to discuss the story.  Make notes for yourself.  In fact it is even better (vital in my mind) to have the conversation involve a developer, tester and product person.  I call them 3-headed conversations.  This allows everyone to be on the same page so later there is no disagreement about what was really meant by the story.  This avoids one of my least favorite conversations which happens when the tester and developer disagree about what the requirement means AFTER the code is written.

If you are using an agile lifecycle management tool rather than physical cards, record the decisions made during the conversation and any resulting confirmation tests in various fields in the tool.  You must make sure the information is captured in case someone else who was not part of the original 3-headed conversation ends up doing some work on the story.

Try using the 3 C’s and see if your results improve.  I’m sure they will.

Until next time I’ll be Making Agile a Reality® for my clients by continuing to train and coach them to use the 3 C’s effectively.

Related posts:

1. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...
2. When in Doubt Ask “How Will I Know I’ve Done That?” Tired of not knowing exactly what to create or test? Get in...
3. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...

Have you ever been in a class or training session which is so boring you felt like you might fall asleep?  Or maybe you are one of the people that DID fall asleep!  I know I’ve been there many times.  When I started facilitating sessions on agile and Scrum I knew I couldn’t do it if the sessions would put people to sleep.  I knew I had to have dynamic sessions that kept people involved and challenged them to exceed their own expectations.  I put together the best sessions I knew how and I was quite successful with it (see the bottom of the sidebar at www.agileforall.com for course results and quotes from evaluation forms).  Attendees were very happy with the results, but I knew I could do better.  Much better. I knew I could talk less and have the attendees do even more.  I knew I could better help the attendees if I could just figure out how to get information across in a different way.

Then something happened which changed my life and will help me change many lives going forward.

A few months ago while searching for some airplane reading material for my Kindle (which I love!) I decided to try and find some good books about training techniques.  There are hundreds of books on the topic of training and many of them sounded more boring than watching grass grow. Then I stumbled across the book “Training From the Back of the Room” and it intrigued me so I made the purchase.  As I read the book I knew I had found a source of information which was going to dramatically change the way I facilitate courses.  Having students teach each other instead of having the trainer teach them?  Having students do homework prior to class?  Not doing introductions until the class is well underway?  Not giving out a notebook with slide printouts?  This was all very challenging for me, but I knew in my heart I had to embrace it in order for me to learn and improve.

Now flash forward a few months…  I’ve now had a chance to facilitate several courses using the new techniques I learned from the book.  The results have exceeded my wildest expectations in a number of ways:

• Allowing attendees to work through an exercise prior to formal introductions means they get to start building relationships with each other and the course material right at the start of class.  The very beginning of the class is the time people remember most when they leave! Instead of wasting that valuable time on introductions my classes now spend it on a meaningful exercise.
• Giving out blank spiral notebooks, pens, lots of markers and other materials instead of a notebook of slides encourages people to take more meaningful notes. Helping them take notes in a particularly meaningful way for a particular topic helps deepen their understanding and retention of the information.
• Having attendees teach each other exposes the combined knowledge of the group and allows me to truly facilitate toward a meaningful result.
• I had always used a lot of collaborative discussion exercises, but having even more and adding twists to them so they aren’t all just discussion helps attendees build relationships and connections with the material in ways that are fascinating to watch.  More importantly, the end result is better knowledge retention.
• Breaking my speaking up into smaller chunks allows attendees to better absorb what I am saying.  I averaged speaking about 10 minutes per hour in the most recent course I facilitated and the results were outstanding in all areas.
• I now average fewer than 20 slides per day for a course.  I won’t embarrass myself by saying what that number used to be!  I could cut the slides down to zero, but I find having key slides helps drive discussion.  In almost all cases the slides have fewer than 5 words (in some cases no words) and a picture capturing something about the concept.  I try to keep the pictures entertaining which keeps attendees engaged.
• I have some handouts I use during certain portions of the course which attendees can save in the pockets of their supplied notebook.  Attendees love getting the essential information in a concise format rather than having to dig through a notebook of slides to find what they want.
• This may be the least important item or the most important depending on how you look at it – I have a LOT of fun facilitating these courses.  Instead of feeling a bit wiped out when I  leave a class, I leave feeling incredibly energized.  I usually have fun with my classes, but this is a new level which is much higher than I expected.

So what does all this have to do with you?  My hope is if you are looking for a course on agile or Scrum (or really any topic) you will take the time to find an instructor who won’t bore you to death.  Before registering you might want to ask a few simple questions (my new answers in parentheses):

• What materials will I leave the course with?  (a spiral notebook with your notes, a set of handouts for critical areas of the course and you will leave having had a lot of fun!  You also get follow-up support via email and in the near future you can join the Agile For All community message board for information exchange with peers at other companies)
• If you use PowerPoint, approximately how many slides are included in the course?  (in my courses I average fewer than 20 slides per day)
• What is the percentage of course time is spent on lecture vs. exercises?  (approximately 15%/85%)

The answers to these 3 questions can be very enlightening.  If you are the type of person that needs to walk away with a book full of slides and you don’t like to interact with others then maybe my new style isn’t for you.  In that case asking for answers to the 3 questions above can still help you choose a course provider!  However, if the last sentence describes you, you might want to reconsider and try a course which challenges your assumptions.  I was scared the first time I tried facilitating a course this way, but even the most reserved people in the room participated and had fun during the course.  That’s when I knew my life had changed and many more would be changed in the future because of it!

Until next time I’ll be Making Agile a Reality for more people by getting even better at training from the back of the room by being more of a facilitator and less of a teacher or trainer!

A special thanks to Roger Brown (CSC and CST) who emailed me today and part of the email was thanking me for recommending “Training From the Back of the Room” to him!

Related posts:

1. New to agile? Do the simplest thing that works – THEN STOP! As an agile trainer and coach I often see new teams struggle with...
2. Agile Architecture and Agile Testing – New Courses on the horizon Exciting news!  Some associates of mine are currently completing work on some...
3. Agile Ponderings: Certification – useful or not? I’ve had to do a lot of thinking about certification recently. Why?...

you would have had an absolutely indescribably fantastic time!  And that’s just for starters.  To be honest, the phrase “that was so much fun it must have been a sin” comes to mind.  I had fun every minute I was there.  Here’s a short VERY LONG recap of what I can recall now (a week after I arrived in Orlando):

Saturday, very late at night I was on a shuttle from Orlando International Airport to the Gaylord Palms Resort and Conference Center.  I was blown away when I saw the Gaylord Palms.  It was a sight to behold.  On the Mears shuttle were about 10 people and I didn’t know any of them.  I was tired and just looking forward to getting to bed.  While waiting for my luggage to be taken off the shuttle someone in the group said “You’re Bob, right?”  Freaky, right?  Well, I was at the hotel hosting the Scrum Gathering, but I was not expecting someone on my airport shuttle to know me!  Turns out it was Bent Myllerup and his wife Kirsten from Denmark.  He recognized me from various pictures.  By the way, Bent is a fellow Certified Scrum Coach.  I got to hear about how they had to fly through Detroit to get to Orlando and they were afraid the luggage was lost, but then it caught up with them.  I felt tired, but they looked pretty wiped out after a REALLY long day of flying.  Little did I know how many more surprises were in store for me!

The second surprise came when I went to check-in to the resort..  The person at the check-in desk ran my credit card for the room and then left to go to another room.  I was concerned about what had happened because the card had plenty of available credit, it was not stolen or lost, etc.  Maybe they lost my reservation?  No, none of the above.  They were out of normal rooms with king-sized beds so he upgraded me to a junior executive suite.  It sounded nice and they weren’t going to charge me extra, so what the heck.  Well, it turns out the room had a decent sized living room area with couch, large chair and coffee table.  It also had a dining area with a nice sized round table and 4 chairs.  I nice den area with an office desk and chair.  A very large bedroom area with a very big looking king-sized bed.  A bathroom with doors to both the entry hallway and the bedroom.  A large walk-in shower.  Let’s just say I was blown away.  The whole suite had to be 450 square feet or maybe even larger.  I felt like I wasn’t worthy, but I wasn’t going to say no.  It was great.  I actually was kind of pumped up when I saw it so I got settled in and did some work.  Next thing I knew it was 2:30am and I had to get up at 7:15!

On Sunday I was fortunate enough to be able to go to the Scrum Trainers and Coaches Retreat.  Wow, what a day!  The day was sponsored by the Scrum Alliance, which was extremely nice of them.  Mike Vizdos volunteered to run things for the day and Jean Tabaka got roped in to help him out at the last minute.  These are two people I really respect.  Mike in particular made it clear the entire day would be about positive energy.  I later learned that this particular event in the past had degraded into something very negative and left everyone with bad feelings.  I’m glad I didn’t attend those other retreats because this one was nothing like that at all.

I spent the day having conversations with amazing people.  Serge Beaumont, Peter Stevens, Jim Cundiff, Roger Brown, Jeff McKenna, Tobias Mayer, Howard Sublett, Lyssa Adkins, Peter Borsella, Alan Cyment and so many others that I can’t remember them all now!  I learned new techniques for using case studies as exercises in class.  I learned a lot about the inner workings of the Scrum Alliance and how things are being turned around.  I learned a lot about facilitation.  I saw various Certified Scrum Master course slide decks and the great ideas they contain.  I interacted with others on a Scrum Alliance Improvement Committee on how best to move our group forward.  I had an amazing lunch with Peter Stevens where we spoke about so many things I can’t remember them all, but he ended up creating a blog entry about part of our conversation involving a quote from Randy Pausch (of the Last Lecture fame).  I remember my head swimming when the day ended just after 4:30.  Then going to the reception later in the evening and having my head spin again as I spoke to even more people who I have long admired but never been able to meet in person.  The night (for me at least) ended around midnight when I left the bar after having spent several hours with Mike Vizdos, Howard Sublett and Andreas Schliep.  Very interesting conversation.  Very open and honest people.  I remember thinking for the first time in a couple of years I really had a good feeling about where the Scrum Alliance was headed.  I had a smile on my face all day and I’m pretty sure I fell asleep that way too!

It turned out I was too jazzed up on Sunday night to fall asleep, so once again I didn’t go to bed until about 2:30.  This time I slept through the alarm and missed the opening keynote sessions.  I normally don’t make it to those anyway, so this conference was no exception.  I did make sure I was at Luke Hohmann’s “Innovation Games® in Scrum” deep-dive session.  I have been interested in Innovation Games for quite a while and this was going to be my chance to see the master at work.  I am hosting an Advanced Product Owner course for some clients at the end of this month and I want to use some of these games so this session was important for me.  Luke did not disappoint.  I think we ended up playing 6 of the 12 Innovation Games including doing a couple of them online.  People kept filing out of this session, but I think it was because they didn’t know what they were getting into.  For me it was pure heaven.  I learned a LOT.  I also confirmed my understanding of some key points I intend to use later this month.

Monday night was a reception sponsored by VersionOne.  It too was great.  Again, meeting great people, making great new friends.  During the day I met Darian Rashid who is so close to me in lean/agile/Scrum beliefs that it is truly scary.  We spoke a bit more during the evening and both were going to try to make it to each other’s sessions on Tuesday (didn’t happen for either of us!).  As the bar was closing I remember them giving Howard Sublett a full glass of bourbon for the road.  Nice parting gift!  I don’t even remember where I ended up after the reception, but I’m sure it was a fun place.  I’m sure it had fun people.  I’m sure I had interesting conversations.  Right now I can’t recall any of them, and no, it isn’t because I was drunk.  It is simply because a week later all of those great conversations are starting to run together!

Tuesday was a big day.  My presentation “Doing Scrum Isn’t the Same as LIVING Scrum” was at 9:45.  I slept late (and missed Darian’s first session) so that I could be fresh for my session.  My session went very well.  I knew the material was great because I gave earlier versions of the same presentation to the XP NYC Meetup and the Phoenix Scrum User’s Group back in January.  I updated the material for Scrum rather than Agile and changed a few slides based on new ideas I had.  It was a total success.  Lots of good ideas, good questions, and a great group of people.  Some standing and some sitting on the floor since we ran out of chairs.  It was awesome.  I had so much fun giving the presentation.

After the presentation was over it was time to simply mingle.  I should have gone to other presentations, but I didn’t.  There were too many interesting conversations to have in the hallways!  I even ended up playing Doctor    Lunch was quite interesting as Harrison Owen spoke about the creation of the open space concept.  My favorite quote in regard to running an open space event was “Sit in a circle. Create a bulletin board. Open a marketplace. You all go do work while I take a nap.”  He was hilarious, yet always making the point that open space can be used to solve very serious problems.  Late in the afternoon the CSC’s met with Howard Sublett in my room (since I had so much space) and had great discussion around a bunch of topics.  Howard is an interesting character and the more I got to know him, the more I liked him.  After the CSC group broke up I spent time that evening getting dinner with a great group including Jean Tabaka, Bent Myllerup and his wife, and several others I can’t remember right now.  When I went to bed on Tuesday night I remember thinking “I don’t know if I have any more energy or brain cells to handle another day!”

Well, turns out I did.  I missed the opening remarks for open space on Wednesday, but I got there in time to go to some sessions.  I spent time with Roger Brown talking to a group of people interested in applying to become CSCs in the future.  That was fun because I got to see the process through their eyes.  It is rather intimidating and being able to help some people understand it was nice.  We can’t give them answers to everything, but we can give them some guidance, which we did.  I felt like I was repaying the guidance and support Richard Lawrence gave me when I applied.  I spent lunch talking more with Darian Rashid.  I still can’t get over how much he reminds me of me in the way he thinks about things.  We are supposed to get together later this month when I’m near Philadelphia.  I’m really looking forward to it.

Unfortunately, the Scrum Gathering did have to come to a close for me.  I left at around 3pm to head to the airport.  Once there I tweeted about sitting at Wendys and 5 minute later James Love who I met in my session at the Scrum Gathering was joining me.  Turns out he has some needs in his organization people I know may be able to help with.  Who knew???  A perfect end to a perfect few days.

Until next time I’ll be Making Agile a Reality® by keeping up my relationship with the incredibly smart people I met at the Orlando Scrum Gathering.

Oh, and thanks to Derek Wade because I blatantly stole the idea and title of this blog post from his blog post!

Related posts:

1. Orlando Scrum Gathering – I’m going to be a doctor soon! In about 5 minutes I’m going to play the role of being...
2. I’m a Certified Scrum Coach (CSC) – so what? I’ve asked myself that question more than once in the 5 or...
3. I’m a Certified Scrum Trainer (CST) – so what? This is a companion post to last year’s “I’m a Certified Scrum...

I’m making my Orlando Scrum Gathering presentation “Doing Scrum Isn’t the Same as LIVING Scrum” available as a PDF.  You don’t have to fill out a form to get it, although if you sign up for my mailing list and/or subscribe to the blog I won’t complain!  Just click the link below to download.

Doing Scrum Isn’t the Same as LIVING Scrum PDF

Until next time I’ll be Making Agile a Reality® for others by working on my next set of presentations!

No related posts.

In about 5 minutes I’m going to play the role of being a “doctor” at the Scrum Clinic which is part of the Orlando Scrum Gathering.  It’s an interesting concept.  A doctor and a patient meet to discuss a topic important to the patient.  In my case the patient wants to talk about the Scrum Alliance Certified Scrum Coach (CSC) program.  Since I am a CSC and all of my CSC brethren wimped out I’ll be the one acting as doctor.  I’m looking forward to it so I’m only kidding about the rest of them wimping out!

More on the Scrum Gathering later this week.  It’s bee great so far!

Related posts:

1. If you had been me at the Orlando Scrum Gathering… you would have had an absolutely indescribably fantastic time!  And that’s just...
2. I’m a Certified Scrum Trainer (CST) – so what? This is a companion post to last year’s “I’m a Certified Scrum...
3. I’m a Certified Scrum Coach (CSC) – so what? I’ve asked myself that question more than once in the 5 or...

My friend, Arif Gangji, and I created this video to help his customers understand why his company uses Scrum as their software development framework. I decided I really liked the video, so I’m posting it here as well. It isn’t perfect, but it is plenty good enough to get across the basic ideas of Scrum. Over time it will probably show up in a few more places on the main website, but for now, enjoy!

Click here to view the embedded video.

I’d love to make our next video even better so if you have suggestions please put them in the comments below.  Thanks!

Until next time I’ll be Making Agile a Reality® by pointing people to this video for some introductory information about Scrum.

Related posts:

1. I’m a Certified Scrum Coach (CSC) – so what? I’ve asked myself that question more than once in the 5 or...
2. Orlando Scrum Gathering – I’m going to be a doctor soon! In about 5 minutes I’m going to play the role of being...
3. If you had been me at the Orlando Scrum Gathering… you would have had an absolutely indescribably fantastic time!  And that’s just...

Have you ever had a computer meltdown?  OK, so myIT infrastructure meltdown wasn’t as total as the picture to the left, but it still was pretty bad.  In the span of a couple of days I had my main desktop and my main laptop both die.  This happened just before I had several straight weeks of travel and as a result I was left working off of my MSI Wind U100 netbook for a few weeks.  Let me tell you a bit about it and what I learned from it because anyone making a living on the road needs to know this stuff!

First off, let me just say super-redundant backup is a good thing.  In fact, it is a VERY good thing.  Because I had backups available in several different ways the outage didn’t cause me to lose any work.  Groove had always worked in the background to sync my files so the netbook was ready to go.  I use an Exchange server so again the netbook was fine since it could sync just as easily as the other computers.  In fact, most of what I mention in my blog post about a highly mobile team of 1 turned out to be necessary!

The big wins for me were:

1. Having all of the files already sync’d from Groove.
2. Having everything in Exchange so I just pointed the netbook to it and let everything stream onto the netbook.
3. Having a netbook which is very capable of running all the Office applications and still be usable.
4. Having enough computer savvy to recognize things were failing and stopping them before they damaged other parts of my IT infrastructure.
5. As usual, Dell came through and delivered my new kick-butt Dell Precision M6500 laptop very quickly.
6. Bringing up the new laptop worked just as my emergency plan said it should!  Install Office, sync w/Groove, sync to Exchange, copy Favorites, etc.  After all the headaches I had, this part of the process was rather nice.

Things that didn’t go so well:

1. The desktop computer was (and is) completely dead.  It powers on and then nothing happens at all.  This really stunk because it had all my personal and family stuff on it.  All of that was backed up, but it still was a pain because I had been very good about separating personal and business items.
2. The laptop would mostly boot, but not quite.  I spent a long time (30+ hours) trying to fix the problem.  Microsoft Windows let me get so close to fixing it, then would make it impossible at the last second.  I wanted to upgrade the Windows on the machine to Windows 7 – no luck because you have to boot from the hard drive for an upgrade to work.  I finally got around that by booting from a USB thumb drive and Windows 7 decided it didn’t know how to talk to the regular hard drive.  Frustrating!
3. My netbook had several Windows Updates, a Java update and an Adobe update to install, but I couldn’t take the chance of installing them.  If the machine crashed I was going to be in big trouble for my upcoming courses.
4. The HP printer drivers once again proved incredibly frustrating for me.  I have NEVER been able to install HP printer drivers and have them work first time.  In this case I installed, uninstalled and reinstalled several times and finally gave up on getting it all working.  I still can’t scan through the network like I could before.  I don’t know why, but the printer is near the laptop so I just plugged in a USB cable and called it good enough.

Things that surprised me:

1. Because I made the decision to just have one main machine (the M6500 laptop) instead of two, I had to put all of my personal information on the laptop as well.  I expected this to be straightforward – copy over old data files, install software and you are up and running.  Wrong.  Quickbooks only allowed a certain number of activations and my backup machines had used those up.  I ended up having to upgrade, which was good, but unexpected.
2. I used Laplink PC Mover to copy data from a semi-working laptop to the new laptop.  I had high hopes for this software, but as it turned out I had to reinstall several items anyway.  If I had known that would be the case I would have just started that way instead of being led astray by the high hopes I had for an easy transition.
3. Windows 7 is really very easy to use and quite nice.  I thought all the advertising was going to turn out to be just hype, but I definitely like Windows 7 - a lot!  Microsoft has made some nice changes.
4. I got a fingerprint scanner on the laptop because it wasn’t expensive and seemed cool.  It is actually very cool.  I can use it to log into the computer but it also came with a program which can store security data for websites.  This can include login information, credit card info, etc.  The difference between this and doing it in a browser is the security involved.  I login using my fingerprint.  It can take a password, but I deliberately made that something even I don’t remember and just stored it in my safe deposit box if I ever need it.
5. I had to put passwords on all of my financial files (Quicken and Quickbooks).  I decided to share these through Groove with the netbook.  I did this because I’m spending more time on the road than I thought I would and I need to keep these things up to date.  Once I did this I realized I needed to protect the data or someone stealing my laptop or netbook would have keys to my financial kingdom.

So in the end I’ve recovered nicely.  I upgraded my laptop and refurbed the old one (a Dell Vostro 1700 I really liked) and gave it to my wife to use.  I now have access to ALL of my vital information on both of my computers.  I still have redundant backup and now I know it works!

I did miss a month of blogging and keeping up with the world though.  For that I’m sorry.  As of today I’m back on the bandwagon and I should start generating more blog entries fairly soon.

Until next time I’ll be Making Agile a Reality® by continuously improving my IT infrastructure and the processes I use to support it.

Related posts:

1. Agile hip surgery? I’m always looking for uses of agile in areas outside of software...
2. Merry Christmas! This blog entry is being posted on Wednesday, December 23 at noon...