Bill Engvall is one of my favorite comedians. The guy just cracks me up every time I watch or listen to him. His most famous line is “Here’s your sign.” So here are a few “sign” stories for you to ponder.

[Imagine Bill Engvall voice]

So the other day I was watching a Daily Scrum meeting at the office and this ScrumMaster was doing something I’ve never seen before. He was asking and answering questions like he owned the place! I may be a bit slow now that I’m getting older, but even I know the ScrumMaster is supposed to make sure this meeting allows the team members to talk to each other and not to others. So, like an idiot, I asked him about it. He said… get this… he said… “If I don’t do the talking, no one will!” Well, Mr. ScrumMaster, here’s your sign!

[still in Bill Engvall voice]

That reminds me of another ScrumMaster I met once under unusual circumstances. I was answering a question from a team member when out of nowhere this ScrumMaster comes up behind me. She had that look that seems to say “You’re a dead man.” You know that look. Right, THAT look. The look your mom or a teacher gave to you when you were disappointing them terrible. Anyway, she gives me that look and I wonder what her problem is. I’m just minding my own business, and besides, it was her team member that asked me the question! It CAN’T be me, right? Welllllll… I’ll never learn my lesson around ScrumMasters, so I asked her what her problem was. Turns out she didn’t think I had a problem, she thought I WAS the problem! According to her, as a stakeholder I should never speak directly to a team member. That’s reserved for her and the Product Owner only. So, Ms. ScrumMaster, for ignoring the agile value of “Individuals and interactions over processes and tools” as well as the principle of “Business people and developers must work together daily throughout the project.” well, all I can say is, here’s your sign!

Finally, one more quick story before I go. The funniest, well, ok, maybe not funniest, but you can decide that in a minute. Anyway, the funniest ScrumMaster ever was the one that told me the team was committed to getting 40 story points done within their sprint. I asked why the team felt that was possible since they had never exceeded 25 points in any previous sprint. The ScrumMaster response was classic: “We calculated the velocity we need to finish all the features before the release date and we need to get 40 points done per sprint, so that’s our new commitment.” I asked what they would do if they fell short in a sprint and the response was those points would carry over to the next sprint and increase the commitment. A couple of sprints later I was in that area of the building again and asked the ScrumMaster how the team was doing. He said their new commitment was 84 points. I looked at the release burn-up chart on the wall behind him and saw that a whopping 27 points was their new high for any sprint. Then I turned and said here’s your sign!

[End Bill Engvall voice]

Ok, so I don’t write as well as Bill Engvall does his routine. I hope you at least see some humor in the stories.  ScrumMasters, please remember that being a ScrumMaster isn’t about YOU getting results. Your role is to help enable the team to be great, while also helping them understand reality.

If you need help figuring out how to be a good ScrumMaster or you have a ScrumMaster who needs help, get signed up for Certified ScrumMaster Training. It will make a big difference in how well the team performs!

Until next time I’ll be Making Agile a Reality^® by helping ScrumMasters recognize when they are about to get a sign – and stopping themselves in time!

Since it is that time of year, I hope everyone has a wonderful and prosperous 2012!

The post With apologies to Bill Engvall, ScrumMasters, here’s your sign! appeared first on Agile For All.

There were arguments about agile even before the Manifesto for Agile Software Development was created in 2001 by 17 brave individuals (some of whom I’m honored to be able to call friends). Lately, I’ve come to realize that the world of arguing around agile hasn’t changed in the past 10+ years at all. The players have changed, but not the fact that we can’t all get along. In the past year I’ve seen “discuss-ments” (give me credit if you use my made up word!) around all of the following issues:

• Is a backlog prioritized, ordered, or should we use some other word?
• Kanban is much better than Scrum, isn’t it?
• Scrum is much better than Kanban, isn’t it?
• Why don’t more people teach XP practices?
• Certified ScrumMaster should be abolished because it is evil.
• Certified ScrumMaster should be enhanced to make it something useful.
• There should or shouldn’t be a test or assessment or essay responses to something asking questions or scenarios or something for people to become certified or certifiable or…
• Certain courses should or should not be allowed to be advertised in certain mailing lists.

I don’t mind people speaking their mind. I do it quite often myself, but I try very hard to do it in a respectful fashion. Today it seems people just shout as loud as they can, as often as they can, and hope people with a differing opinion will just acquiesce. I’m pretty sure that in the history of mankind that has never actually occurred, but it doesn’t stop people from trying.

Too many people seem to believe life is a zero-sum game. If you win, then they must lose. I don’t believe it works that way. It could work that way if greed was everything to everybody, but it isn’t. When you give up trying to win it all, you often end up winning in unbelievably wonderful ways. It is Christmas time and during this time of year you can always find heart-warming stories of incredible charity (like this one and this one). If life were a zero-sum game, would things like this ever occur?

There is always a win-win out there to be had. Make it a personal goal to go find the win-win rather than escalating to using a flamethrower to make a point. Treat people with respect and dignity and you will be pleasantly surprised at how things can change. The Golden Rule “treat people as you would like to be treated” is still good advice no matter how old it is! When was the last time you actually thought about the Golden Rule in a way that mattered?

Of course, I’m saying this in an environment where people in the US Congress are appearing to treat each other with respect and dignity by calling each other “esteemed colleague” or “friend from the other side of the aisle,” but it is all for show and not real. Do you really think the Speaker of the House and the Senate Majority Leader actually like each other? It’s pretty obvious the people of the US don’t like them much!  One of the Scrum Values is to be transparent and open. Another is respect. Doing both at the same time works better!

I don’t expect the agile world to stop their discuss-ments overnight – or ever. What I sincerely hope is a renewed effort at respecting the differences we have and understanding we can all be right (and all wrong) at the same time. None of us is perfect, nor are our solutions or ideas. The best of the best uphold agile principles around continuous improvement. Ask yourself if it is possible for you to be at least partially wrong? If so, then there is room for improvement. The day you say you are completely right is the day you are probably no longer being agile because you can always improve!

How does this apply to teams? Let’s make it a bit more real now. On agile teams, don’t blame people or other parts of the organization for the issues you have. Those things happen based on the process and expectations in place. Change the core items! Don’t just put a band-aid on it by glossing over the issue. Don’t try to say it won’t happen that way again (and this is how many times you’ve tried the same thing and received the same result???). Make a change and adjust based on how the change worked or didn’t work. Plan, Do, Check, Act or Transparency, Inspection, Adaptation or something else – it doesn’t matter which, they all say to TRY SOMETHING DIFFERENT!

For me, the something different, is going to start right now. I’m going to add a module to my workshops around dealing with conflict. I’ve seen enough of it being detrimental to enough agile teams, and at this point enough is enough (did I use enough enoughs in that sentence?). Don’t want to come to a workshop? No problem, start reading about the subject. Collaboration Explained by Jean Tabaka, Crucial Conversations by Kerry Patterson and others, Managing Transitions by William Bridges and many other books are great starting points for how to have needed conversations and make them effective.

For me it is the time of the year to consider gifts and changes. If it is for you as well, then consider this blog entry my gift to you as it is also a challenge to think about change!

Until next time I’ll be Making Agile a Reality^® for organizations that are having too many discuss-ments!

The post Agile Practitioners Aren’t Supposed to Use Flamethrowers – Are They? appeared first on Agile For All.

Below is a message from a recent workshop attendee that really hit home and made me realize adding this little segment to the CSM workshop was well worth it! He had the patience required of a good ScrumMaster and the result was worthwhile.

Bob,

I wanted to share a story with you that I think you’ll appreciate.

First, some background:  I’m leading a large project that can hardly be called agile.  It’s basically fixed-scope waterfall with short development cycles, but I’m trying to take as much advantage of scrum principles as I can.

Coming out of my CSM class, my biggest takeaway in terms of things I could be doing better within the constraints of my non-agile project was to hold regular sprint retrospectives.  The first thing I did when I got back in the office was to put one on the schedule.  That first one took a little bit to get going, but I was careful to remember to keep my mouth shut and let the team do the talking, and they eventually identified a variety of things that had been working well and not so well.  I was particularly pleased with the fact that they came up with the same list of “not good” issues I would have identified if I had been doing the talking.

Since the CSM class, we’ve now held three sprint retros following very closely the guidelines you laid out, and the results have been incredible.  With each one, the team has identified the top 1 or 2 issues they want to work on, laid out a plan for addressing them along with a team conscience to keep them honest and followed through to become more productive and successful as a result.  They have fixed all of the issues I was initially concerned about; and although new ones have come up, they’re now quick to identify them and put a plan in place to fix them.

Here’s the kicker.  In our latest sprint retro completed last week, one of the items on the “working well” list was, you guessed it, the sprint retros themselves!  The team loves taking that time to figure out how to get better at what they do.  There’s no longer any prompting or patience required on my part to get the discussion going.  All I have to do is sit back, take notes and watch the team figure out how to succeed.  How cool is that?

From Brennon M. to Bob Hartman on November 15, 2011

Until next time I’m hoping I’ll be Making Agile a Reality^® for more of the people who attend my workshops!

The post As a ScrumMaster silence can be golden! appeared first on Agile For All.

I want to give out Christmas wishes!  So here goes…

1. To my colleague and friend, Richard Lawrence, my wish is for a great 2011 including publication of his first book.

2. To the Scrum Alliance, my wish is for a Certified Scrum Trainer acceptance and recertification criteria that works for the majority of the stakeholders in the process.

3. To the Agile Alliance, my wish is for Agile2011 to be a great success with fewer speaker controversies than in the past (ie, pick me this time – only kidding, a little).

4. To the Marriott hotel chain, my wish is for a lot of promotions I qualify for since I stay almost exclusively in Marriott properties and would like to keep it that way!

5. To United Airlines, my wish is for a continuation of flights and times to the destinations where I travel often. (I’m worried about service cuts after the integration of Continental Airlines)

6. To people who attend my workshops, my wish is that you will see workshops that are even more fun and interactive in 2011, but more importantly, that the information will stick with you and be useful!

7. To Agile For All clients, my wish is for a prosperous 2011 with increased delivery of business value due to using and being Agile.

8. To my friends and colleagues who are part of Agile Denver, my wish is for a great Mile High Agile 2011 conference on April 7.

9. To Mike Cohn, my wish is for incredible patience as he deals with the Scrum Alliance from his position as Chairman of the Board.

10. For my family I wish for an awesome 2011 including 2 major graduations, other major events (dive meets, Improv shows, Prostart competitions, etc.).

Until next time I’ll mostly be on vacation so I won’t be busy Making Agile a Reality^® for anyone for a while.  Have a Merry Christmas, and if I don’t write again before then, a Happy New Year too.

The post An Agile Merry Christmas 2010! appeared first on Agile For All.

Richard Lawrence – Richard has been a great friend and colleague.  We have worked together at many clients over the past couple of years.  Richard continually keeps me on my toes, challenges my assumptions, and flat out makes me better every time I interact with him.  I hope to continue working with him for many years to come.  Without Richard I probably would not have started down the path to become a Certified Scrum Coach and later a Certified Scrum Trainer.

Cindi Taylor - Over the past 2+ years Cindi has become a friend more than a client.  Her company was one of the very first to use me as an agile trainer and coach.  It took a lot on her part to hire me over many others trying to get their business.  I have always appreciated that trust.  Over time her organization has been my largest client and I believe we are both very happy with the results we see.

Greg Adams-Woodford – Greg was instrumental in getting me hired to work with the teams in his organization.  His support and insight has always been great and I like to believe I’ve helped his teams become more successful.  Greg also pushes others to try agile and always recommends me to them, which is great from a client/vendor perspective.  But more than that, Greg and his organization are probably the most fun teams I work with regularly.  They always make me feel welcome and together we find ways for them to continue to improve.

Mike Cohn - Mike was very instrumental in helping me become a Certified Scrum Trainer.  I’ve learned much from Mike’s books and presentations.  If you can only read one book about Agile make sure it is one of his!  Mike has always been great to me and I really can’t say enough about how great a person he is.

Luke Hohmann - Innovation Games changed many of the ways I approached things.  I’m almost embarrassed to admit that I’m NOT a certified Innovation Games Facilitator.  Luke just keeps having courses when I can’t attend them!  However, I use many of the games from his book in nearly every engagement.  I’ve interacted with Luke at conferences and via email and I truly enjoy what he has created.  He certainly added tools to my agile coaching toolbox.

Jake Calabrese and Alex Viggio – Both of these gentlemen graciously allowed me to speak to their organizations back when I wasn’t known outside of my own house (or so it seemed).  Thanks to Jake I spoke at a Denver IIBA meeting  and continue to support and be supported by IIBA.  Alex allowed me to speak to Agile Denver which I think is one of the top Agile user groups in the world.  Both are great organizations and I’m happy to support them and really appreciate the support I get from members of both organizations.

Alan Shalloway - Alan is the owner of Net Objectives and he hired me to work there several years ago.  During my time with his company I learned enough to fill several bookcases with information.  He was my boss, my mentor and my friend.  I was a sounding board for his ideas which we would discuss for hours at a time.  Interestingly, I disagree with Alan about as much as I agree with him, but we both know it is because of our different experiences.  I love our discussions when they are face-to-face.  When we try to do the same thing in email or via Twitter it doesn’t have enough context for me.  I still consider Alan a dear friend that I know I could count on if I needed someone to help me in a pinch.

Tobias Mayer - Tobias challenged (and continues to challenge) me to be the best I can become.  His belief in me came at a very crucial time in my development as a trainer and coach.  His openness and honesty helped me understand some things about myself I had been struggling with at the time.  I’m sure Tobias will have no idea what I’m even talking about if he reads this, but trust me, it was important to me at the time (and still is!).

Pete Behrens - Pete has been a mentor from afar.  He is efficient and successful.  Pete is impressive in so many ways.  I was honored when he agreed to let me co-teach a CSM class with him and then a few days later showed up to watch me teach an Advanced Product Owner course.  I learned a lot from him, and he even learned a few things from me.  I wish we had more time to interact and work on things together.  I do know that any time I spend with Pete is precious to me because I always walk away better for the experience.

Lee Copeland - Lee gave me opportunities to speak at Software Quality Engineering conferences including STAREast, STARWest, Better Software and Agile Development Practices.  I enjoy speaking to conference audiences because even though the time is short I feel like I can connect with the audience in a way that encourages them to dig deeper.  I like seeing people leaving a room talking about how I opened their eyes, or they have to think about a particular thing I mentioned.  That’s always a great feeling.  Lee gives me that opportunity on a fairly regular basis.  I think these speaking engagements help sustain my growth as well because they give me opportunities to interact with large numbers of people outside my normal circle.

Ken Schwaber - Ken was the trainer for the Certified ScrumMaster class I took to become a CSM.  As such he deserves to be on this list since it was really my official start into the Scrum community.  I’m certain I don’t agree with everything Ken has done since, but I do know those things I disagree with don’t come close to overshadowing his involvement in the creation of the Scrum framework.

David Bernstein and Scott Bain - 2 more people I met during my days at Net Objectives.  For the past few years my courses have always had high scores based on attendee evaluation forms.  I will admit with no shame that it is because these two great gentlemen helped me understand how to truly be a trainer.  They are both extraordinary at what they do and their results always challenged me to get better.  I may never reach their training proficiency, but I’ve closed the gap quite a bit because I had insight into how high a bar they both set.

Sharon Bowman - Sharon wrote “Training from the Back of the Room” and I am so thankful she did.  That book changed my life completely.  I hope in some small way I’ve paid her back for that life changing experience by recommending her to EVERYONE I know.  The Scrum Alliance even partnered with her to do some classes for Certified Scrum Trainers.  I’m so excited that I’ll get to be in one of her classes on December 6 and 7 in Seattle, WA.  I’ll be there with several friends so it will be even better.

Greg Schwartz - Greg gave me my first opportunity to work with an institution of higher education.  It was an amazing experience that has now translated into more engagements of the same time with other colleges and universities.  Their challenges are unique (and unlike most regular companies, in this case they really do have unique challenges) and their motivation for success is amazing.  I always have a great time with Greg’s team and teams from other universities.

Fellow Certified Scrum Trainers and Certified Scrum Coaches - Becoming a member of each of these sub-communities of the Scrum Alliance has been an incredible experience.  How can you not feel like your head is going to explode from learning when you can interact with Lyssa Adkins, Jeff Sutherland, Alistair Cockburn, Mike Cohn and many, many others too numerous to name?  I think I learn more every month from reading messages in those mailing lists than I learn anywhere else.  It is truly amazing to be associated with these people.  I wish we could all get along better at times – we tend to have egos that class – go figure   But even with all the clashing we do, at the end of the day I believe we are all motivated to help people be successful and that is an admirable goal!

My clients - Each of them helps me learn something new.  Each of them has shaped me in ways I’m sure I will never know.  Well, ok, in one case I do know they shaped me by coining the nickname “Agile Bob” (thanks Marianne M.).  Most of the time it is only when I look back and realize they impacted me because I’m now using a quote, or a story, or a way of looking at something from that engagement.  To all of my clients, thanks for letting me work with you, and thanks for everything I’ve learned while helping you!

My family - This list would not be complete without mentioning my family.  For privacy reasons I won’t mention them by name here.  They are truly the joys of my life.  I wouldn’t survive without them.  I spend a lot of time traveling and they make coming home worthwhile.  Getting text messages, emails and phone calls while I’m traveling makes the days go by so much faster.  Their support truly gives me the strength I need to be successful.

I’m sure I missed many, many people.  Because I interact with hundreds if not thousands of people each year it just isn’t possible to thank or remember all of them.  In fact, I’m terrible with remembering names, so the ones I listed are pretty lucky I remembered theirs at all!  Seriously though, if I slighted anyone by not mentioning them, please don’t take it personally.  Hopefully I’ve made it obvious to you through my interactions with you that you are important in my life.

Until next time I’ll be Making Agile a Reality^® for more people by remembering how I got here (small steps and many people helping me!).

The post Overdue Agile and Scrum Thanks appeared first on Agile For All.

Tobias recently wrote this blog entry which has come to be known as “Tobias’ Rant” by those in the Scrum community.  I won’t say he didn’t have the right to write it because he does.  What disappointed me is the tone and some of his characterizations and generalizations.  I recognize Tobias was/is frustrated by what occurred, but at the same time I believe he overreached in several areas of his blog post.

I don’t want to address his post point by point.  Instead I want to give my view of the Scrum Alliance and the current state of the Scrum community.  Before doing that I do need to give total disclosure: I am a Certified Scrum Master, Certified Scrum Professional, Certified Scrum Coach and Certified Scrum Trainer.  I pay the Scrum Alliance a handsome fee each year in order to maintain my certification status.  I make money as both a Scrum coach and trainer.  Obviously that makes me biased in many ways.  However, I believe people who know me would agree that money is the last thing I worry or care about and that usually makes me a pretty fair judge of most situations.  I also personally know at least two members of the Scrum Alliance Board of Directors.  Now that you know all that you can decide whether to read on or not.

Where is the Scrum Alliance today?

If I had to pick one word I’d pick… lost!  But not nearly as lost as it was a year ago.  Let me explain a bit.  The organization got lost two years ago and is still lost, but it seems to be slowly finding it’s way back to civilization.  It is now only “lost” rather than “LOST!!!” like it was two years ago.  During the past two years the pace of change has often been painfully slow at best, but at other times the change has happened rather quickly.  Tobias hoped he could help transform the organization and was distraught by the slow pace of change.  I suggest anyone who has had experience trying to change a 100,000 person organization would say change would be rather slow, even if the change was the best thing which could occur.

The Scrum Alliance is HUGE in terms of membership.  If you consider the community of Certified Scrum Coaches, Certified Scrum Trainers and Registered Education Providers there are 150 individuals who all could be considered high level stakeholders looking out for their own best interests.  Have you ever tried to transform an organization with 150 VP’s?  Or even 150 Director level people?  We don’t usually look at it that way, but in reality this is what the Scrum Alliance is today.  It is a very large organization and those that are at the upper levels all have their own best interests in mind.  It is very difficult to steer a ship when there are 150 hands on the wheel.

The good news is the Scrum Alliance recently hired Donna Farmer as the new Managing Director.  She has significant experience and so far seems to understand where the Scrum Alliance is really at today.  She has already made some sweeping changes.  Some of which I’m happy about and some of which make me a bit distressed.  She apparently didn’t get the memo about change taking a long time – and that’s a good thing!  She may not have all the answers, and she may very well make some mistakes, but she is moving forward swiftly and with conviction.  If she can correctly discern when things aren’t working and make appropriate corrections I believe the long term future of the organization is in good hands.  If yet more wrong paths are taken and not noticed, well, it won’t really be much worse than the past two years were.  She is at least “failing well” which I mentioned in this blog post as something important for agile organizations to embrace and understand.

What about the Certified Scrum Trainers?

This is a group I can’t possibly hope to describe adequately.  In various articles on the web they are either:

• greedy, money-hungry low-lifes
• great people trying to make the world a better place
• the ones that have all the power
• the ones that have no power
• great trainers
• lousy trainers
• people who willingly give back to the community
• people who take whatever they can get from the community
• …

The list goes on and on and for every bad example there is another good example.  Unfortunately, I can agree with all of the statements listed.  They are all true, and they are all false at the same time.  Like any sufficiently large organization there are people who fit in all those categories, many of them shift between categories constantly.  From what I am exposed to as an “insider” I believe far more fall into the good side of each list rather than the bad side.  In fact, I’m not sure I can think of even one CST that fits in the bad category far enough for me to be concerned about it, but if I were to just draw a good/bad line, some would be on the wrong side (in my opinion and no, I won’t name any names!).  We don’t all share the same philosophy, we don’t all share the same teaching style, we don’t all share the same business strategy, but we do all teach Scrum and we all do it hoping people will leave our courses knowing more than when they arrived while feeling it was worth their investment.

So why don’t the CSTs do more to change things?  Tobias is right in that area I think.  The Board of Directors does have a lot of control over what can and can’t be done by the membership, including the CSTs.  I have great respect for Ken Schwaber and what he did to get Scrum rolling, but I believe part of the current dysfunction is due to his style of organizational leadership.  It seemed to be more about protecting the Scrum framework than it was about people.  As an original signatory of the Agile Manifesto I would have expected Ken to put individuals and interactions over processes and tools, but it doesn’t seem to have happened that way.  From the outside looking in (I was not an “insider” during those days) it seemed very command and control and rigid.  As a result the power in the organization as a whole was very centralized to a chosen few.  That is changing now, but it is slow change.

The biggest problem with the CSTs as a group is that they aren’t cohesive at all.  They are from varied backgrounds and experiences and it seems like almost every time there is an issue it is 50.1% on one side and 49.9% on the other.  No one feels comfortable claiming that as a majority and making a change.  Because we are all busy people we tend to not collaborate as well as we should – and that is sad since we all teach about this stuff!  Part of the problem is we have many who “abstain” or just don’t participate.  When we have 50-50 and there are 70% who don’t make an opinion known, it really stinks.  Other times it seems there may be a 90%-10% majority, but the minority is exceedingly vocal and don’t allow things to occur.  Yes, we are bad examples in that regard.  Consider it our dirty little secret and don’t tell anyone!  We don’t currently seem to have a good way to reach any sort of consensus.  If this doesn’t change the CST community may never be able to have a substantial voice.  Considering the money we pay to the Scrum Alliance (funding the vast majority of everything else the organization does) this seems pretty silly on the part of the CSTs.  I believe certain individuals will step forward and make some difference with this, I just don’t know when or how.  I try to stay engaged with various conversations, but it is time consuming and often frustrating.  I consider it a sacrifice I have to make to protect my investment.  I wish others felt similarly.

What about ScrumMaster certification, isn’t that a sham?

On my really bad days I sometimes almost believe that the answer is yes.  Then I’ll get an email from someone who was in one of my Certified ScrumMaster Workshops saying how the class completely changed them and the way they do things and their company is now being more successful because of it.  Are we certifying that people are masters of Scrum?  No, we aren’t.  Are we certifying that they were exposed to Scrum concepts and techniques that successful ScrumMasters can and should use?  Yes, we are.  Do I wish they hadn’t used Certified ScrumMaster because it could be considered misleading by some?  Yes, I wish we could roll back the clock many years and change that, but that horse left the barn a long time ago.  The goal now should be educating people that CSM is the beginning of the journey, not the end.  Certified Scrum Professional should be what people in HR departments look for, not CSM.  CSM is great for an entry level position as a ScrumMaster, but if you want someone experienced in Scrum you need a CSP.  That message has not yet been heard.  Thankfully, the Scrum Alliance has been moving that way for the past year and I hope will continue to move that way.

I believe certified courses come with certain assumptions and chief among them is that the trainer is skilled and experienced enough to have a great class.  A Certified ScrumMaster course goes both ways:  the participants get a certification, but it is also taught by someone who is certified to teach the material.  That should mean something, and I believe it does.

At the end of the day isn’t it all about the money?

I wish I knew the answer to that.  For me it definitely is not.  I truly love what I do every day.  I believe I’m passionate about it and do it well.  I also make a good living at it, by working hard to deliver exceptional value every day.  Gone are the days when someone could show up to teach a CSM class once per month and make $20,000 per month (if those days even existed for the majority of Certified Scrum Trainers).  OK, maybe those days aren’t gone for some of the more famous people, but that is nowhere near my experience so far.  Most CSTs do it as a full-time job and they love it.  They make good money, but none I know are going to buy their own tropical island based on their income from teaching CSM courses.

Now, for the Scrum Alliance the answer may be different.  In general the finances have been opaque to the membership.  That is just plain wrong.  There is no excuse for this.  I also know based on recent messages that it is going to change.  Once the finances of the organization are available for us to look at then maybe we’ll all have a better idea of where the money goes.  I think we’ll find way too much money spent on things we believe are overpriced, but I don’t expect to find gross malfeasance in any way.  At least not for the past year.  Too many good people have been involved.  When it was a command and control environment things could have been different, but even then I would consider it a stretch.  I’m sure I’ll disagree with amounts and types of things they spent money on, but I’d be shocked if I found something truly disturbing like paying million dollar salaries or stadium naming rights being purchased.  On the other hand it is disappointing that some influencial magazines and other venues have not had significant advertising dollars spent on them.

What I’m doing to change things

I know this has been a really long, and for many of you, a really boring, blog post, but I needed to get this out in the open.  It seems too many people have just read Tobias’ side of the story and are now overly concerned.  Tobias is a great person.  I still consider him a friend and colleague.  I also know his view of the world often doesn’t match mine.  That’s ok and I think we can both respect that we have differences of opinion.  Given his personality and his passion I completely understand how he came to some of his conclusions.  Fortunately, I think the Scrum Alliance recognizes that some of his points have validity (while some others are somewhat incorrect) and they are trying to make improvements in those areas.  I don’t see the situation as dire as Tobias does.  I might also be wrong.  I have been trying to work to make a difference within the boundaries that have been set up.  Toward that end I have:

• Been a member of one of the Certified Scrum Coach (CSC) application review teams.  One goal of the Scrum Alliance is to grow the number of CSCs in the community while maintaining the highest standards.  CSC is probably the hardest certification to get at this point.  I always learn from others as we look at applications and consider this a good investment of my time.  My role in this may change in positives ways in the coming few months and I’m excited about that too.
• Worked on the CST application improvement committe and the CSP improvement committee.  The CSP-IC didn’t do a lot, but the CST application group did a ton of work.  At the end of the process something was put in place which was perhaps too idealistic, but if the goal was to only allow qualified candidates then I think it did well.  It just wasn’t terribly efficient and relied on CSTs to do too much without guidance.  I hope to be able to help give feedback on any new process the Board of Directors may consider approving.
• I have offered to co-train with any CST candidates at any of my public courses.  It is my way to give back to the community and to help grow the next generation of CSTs.

I do lots of speaking about Scrum to user groups, conferences, etc, but the items above are more specific to the Scrum Alliance itself (if you want me to speak at a local user group, email me – I may be in your area!).

Conclusion – more people need to take action!

Hopefully people take Tobias’ blog post as a call to action, not a sign of defeat.  He did his best and feels it wasn’t enough.  I’m not nearly at that point yet.  I believe we have something special which is worth working for and saving.  I would believe that even if I wasn’t a CSC and CST and the proof is that I was successful doing coaching and training for 2 years before becoming a CSC.  I was not convinced I should support the Scrum Alliance by becoming a CSC (and later a CST), but in the end I decided to do it.  I’d make the same decision today.  I challenge those of you that are currently CSMs to show your passion for Scrum by becoming CSPs and spreading the word that CSP is the “right” certification to be looking for in the future!

Until next time I’ll be Making Agile a Reality^® by helping the Scrum Alliance become the organization it should be.  If you have something you plan to do to help, please post a comment here.  I’d love to see a hundred people all say they now have a goal of becoming a CSP or a CSC or a CST (I’ll co-train with you!).  Our community can use you!

The post In defense of the Scrum Alliance appeared first on Agile For All.

1. True Agile is rarely practiced. I’m not even sure what this means so it is difficult to compare.  The description seems to imply Agile is a good thing and the fact it is rarely practiced correctly is the bad thing.  If so, then I disagree with the premise.  More and more companies are turning to highly skilled trainers and coaches to help them achieve something that can be called Agile instead of agile.  Of course, the alternative is, *cough* *hack* *gag* waterfall.  Even if Agile isn’t practiced as much as I’d like, agile is practiced, and mostly without the caveats presented by the original author.  Advantage: Agile
2. Heavy customer interaction is essential.  This is certainly true for OPTIMAL results.  Just as it is true for any waterfall project.  One of the leading success indicators for projects of any type or size is customer involvement early and often!  Both sides win when this is the case.  Advantage: neither.
3. Agile thrives with co-located teams.  This statement is absolutely true.  Co-location will help Agile teams a lot.  Co-location will help waterfall teams as well.  However, waterfall teams will not take full advantage of the situation because their interactions are fewer.  If a team is not co-located I believe both Agile and waterfall teams will suffer equally.  In many cases the waterfall suffering will be worse because things can fester for longer before it matters.  Advantage: Agile
4. Agile has difficulty scaling for large projects and large organizations.  I’m not even going to give this one any credence by answering except to point people to Scaling Software Agility, The Enterprise and Scrum and numerous other books and papers on the topic.  Agile scales at all levels just fine.  Waterfall on the other hand… what is the percentage of large waterfall projects delivered on-time?  Oh yeah, that’s right – nearly none! Advantage: Agile
5. Agile is weak on architectural planning.  I’m going to say it is harder in many cases to do architecture well in Agile.  Teams struggle with the concepts.  A big up front design is easier to manage, but not necessarily better.  I’m going to throw a bone to those who say “hard” is the same as “weak” and say… Advantage: Waterfall.
6. Agile has limited project planning, estimating, and tracking. This statement is true, but… it is because it has been proven that having more doesn’t help!  Waterfall has all kinds of project planning, estimating and tracking and things still don’t work well.  Advantage: Agile
7. Agile requires more re-work. Studies show refactoring, when there is sufficient automated test coverage, is cheaper than overbuilding up front.  Agile does seem heavy on refactoring.  However, I’d rather refactor prior to release than release the wrong thing! Advantage: Agile
8. Challenges making contractual commitments. Agile contracts are difficult to write well and difficult to get customers to agree to use.  They are possible and many companies are being successful with it, but until there is more work done in this area I think it remains a bit of a sticking point. Advantage: Waterfall
9. Agile increases potential threats to business continuity and knowledge transfer. Light on documentation simply means the appropriate amout of documentation is written rather than too much documentation. Advantage: Agile
10. Agile lacks attention to outside integration. The detail the author provides for this one is just misleading and wrong. A good Agile team will identify technical risks early and address them. In addition, integration points would be clearly defined and encapsulated in some way if possible so late integration would not hurt anyway. Advantage: Agile

As you can see, Agile is the winner.  I did give a couple of rounds to the competitor, but mostly because they are difficult concepts to master, not necessarily because I think waterfall handles them any better.

Until next time I’ll be Making Agile a Reality^® for my clients by helping them utilize real Agile, not something based on myths.

The post Your Agile isn’t my Agile! appeared first on Agile For All.

I last updated my blog on June 14 and here it is July 27.  That is way too long between updates, so let me start by apologizing to all of you who look forward to reading entries when I post them.  Fortunately, during the time when I haven’t been updating the blog I recognized a problem which I often see on agile teams – CRAZINESS!  Yes, sometimes things get a little crazy, or in my case recently, a LOT crazy!

My last month has been extremely busy.  Since June 14th I’ve been in San Diego (twice), Minneapolis (twice), and Philadelphia.  I’ve also sent out 8 training or coaching proposals, been on 18 conference calls, attended 3 major springboard diving meets with my son, one of my daughters had her gall bladder removed and my brother visited to do 10 days of handyman repairs around my house!  In my calendar I see that I did all those things, but it still amazes me that they all got done.  What didn’t get done?  Well, this blog for one thing!

Why is it important to point out my “lack of dedication” to the blog?  Because the answer is much more interesting than “lack of dedication.”  In fact, I love writing blog entries.  It isn’t lack of dedication at all, but rather lack of time.  I made a conscious decision to do other things rather than update the blog.  Why?  Because I work in an agile way, and when I prioritized my backlog of work it caused writing blog entries to fall near the bottom of the list.

I often see agile teams saying things like “we can’t get it all done” and then they try to do the impossible.  The result is usually ugly as they cut corners to try to make everything fit after saying it wouldn’t fit.  Instead what these teams need to remember is to continue to honor their prioritized product backlog.  Work on the important items and don’t spend any energy working on items that aren’t important.  For me, not writing this blog was a tough decision.  Writing here is a bit like therapy for me.  However, for the past 5 weeks I’ve had to put it on hold because other things were much more important.  Will I have dry spells like that again?  Probably, but when it occurs it will occur because I’ve made a decision to prioritize other things higher on my backlog.

Good agile teams need to remember that things WILL get crazy.  It is during the periods of craziness that the discipline of their approach works in their favor.  Don’t fall back into old habits when the pressure or craziness starts to get out of control.  Go back to basics and continue to work in priority order.  Working faster usually leads to more errors.  Working diligently in priority order will always outperform working “faster” on everything at once.

Until next time I’ll be Making Agile a Reality^® for my clients by continuing to prioritize my work and personal life in a way which will lead to a balance where I can deliver maximum value to everyone.

The post New to agile? Remember, sometimes things get crazy! appeared first on Agile For All.

Agile teams will have times when they “fail.”  I know a lot of people dislike using the words “fail” and “failure” when talking about team results.  I’m actually pretty tired of that argument because I don’t think it helps anyone.  I’d rather call a “poor result” a “failure” and acknowledge we can and will strive to do better next time.  As I say during workshops I facilitate, “I am blunt and reality based. Sometimes that means I will say things which you won’t like to hear.”  I don’t call teams “failures” or anything like that.  That would be namecalling and that is never appropriate.  However, calling results a failure is correct and leaves no room for interpretation.  I find being blunt in those situations to be more useful because teams then must face the reality and not try to sugar coat it as “not being all that bad…”

What comes out of failure is what I care about.  I don’t care so much how it happened, why it happened, who supposedly caused it to happen, or that it wasn’t all that bad really.  What I care about is acknowledging there is a problem that needs to be solved.  In my experience I find it easier to digest and solve if failures can be limited to happening only if 3 conditions can be met:

Conditions for acceptable failure

1. Fail FAST!
2. Learn from it.
3. Don’t do it the same way again.

Teams which keep these three simple conditions in mind when dealing with risk they often find themselves making better decisions and reacting more appropriately to the results of those decisions.  The areas of highest risk are where we are most likely to encounter failure, so how will we limit the timeframe to failure?  If we fail, what will we learn from it?  If we fail, how will we avoid failing in the same way again?  This is the heart of improvement.  Be open and honest about the result (failure).  Limit the damange (fail fast).  Examine the failure closely (learn from it).  Try a new way to solve the problem (don’t do it the same way again).

I see too many teams accepting failure time after time after time.  It is very frustrating to the organization and sometimes the team doesn’t even acknowledge there is a problem.  They keep saying they can’t do anything about it or it is an “acceptable failure.”  What does that even mean?  Acceptable to who?  Last time I checked, none of my clients were particularly pleased about failures.  This is where it gets dangerous to call a failing result anything but failure.  Calling it something else makes it somehow more palatable and easier to ignore.  Getting past difficult failures is the time of greatest learning and improvement for teams.  It changes regular teams into high performing teams, and high performing teams can become hyper-productive teams.

Don’t blow failures out of proportion (it really isn’t the end of the world), but at the same time don’t ignore them either.  Teams must deal with failures and turn them into successes downstream.  If they don’t do this then the failures will continue to cascade and cause a loss of morale, loss of urgency and ultimately a project or organizational failure.  Not dealing with failure is leaving a fuse lit on a ticking time bomb – I hope you defuse it in time!

Until next time I’ll be Making Agile a Reality^® with my clients by continuing to make sure they all understand the 3 conditions necessary for failure to turn into eventual success.

The post New to agile? Learn how to fail well appeared first on Agile For All.

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)!

The post Agile antipattern: Target fixation appeared first on Agile For All.