Have you ever been in a flamethrower war? I sincerely hope you have never been in one like the picture, but if you have been there serving for the US armed forces, then thank you for what you did for our country! Most of us have not been in a literal flamethrower war, but some of us have been in our share of them in the virtual world. I may be showing my age, but we used to have a phrase for arguments on message boards: flame wars or flaming. They were all the rage when a social network was really a Usenet newsgroup. Now we’ve grown up to using fancy mailing lists from Google and Yahoo and we still have the same core issues around disagreements. People will make statements in a message that they would never make in a face-to-face environment.

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!

No related posts.

Have you ever had the feeling someone REALLY didn’t get it?  I had that feeling recently when reading this article about the supposed weaknesses of agile.  Some of the 10 points make a bit of sense, but what seems to be missing is what happens in a non-agile scenario with the same limitations?  I decided to write this blog entry to show what I think would occur and to do a bit of a bake-off between agile and non-agile teams for each point raised by the writer of the article.  So, without further ado – drum roll please – welcome to… Your Agile Isn’t My Agile.Let’s get right to it.  Starting with number 1 and ending with number 10.

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.

Related posts:

1. Agile and various bodies of knowledge (PMBOK and BABOK) In case you aren’t aware, there are at least two international organizations...
2. Are you agile – the Nokia test I’ve been helping lots of clients start new agile initiatives recently.  This...
3. 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...

Do you ever get so frustrated you feel like pulling your hair out?  I do (although that is NOT a picture of me to the left!).  If you look at my pictures you will see that it would be difficult for me to pull my hair out because a) there isn’t a lot of it, and b) what little there is I have cut very short.  But, enough about me, back to the issue/craziness at hand.

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.

Related posts:

1. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...
2. New to agile? Remember to eliminate waste When I teach any agile course I start out with the principles...
3. New to agile? Remember how to say “No” No.  Only two letters.  Very simple word.  Yet for some reason, with...

Is success or failure really a choice?  I don’t think it is at all.  Pretty much no one chooses to fail.  Unfortunately, we can’t just choose to be successful either.  What we CAN choose is to try to make a success out of a failure!  The old saying “Make lemonade out of lemons” really is a good way of looking at things, especially for agile teams.

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.

Related posts:

1. New to Agile? Beware of the elephant in the room! Like many other agile consultants I am often asked how agile adoptions...
2. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
3. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...

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: 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...
2. Agile Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...
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. 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. In defense of the Scrum Alliance Have you ever felt really let down by someone you respect?  I...

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

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. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...
3. When in Doubt Ask “How Will I Know I’ve Done That?” Tired of not knowing exactly what to create or test? Get in...

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 Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...
3. Free Event! Agile Adoption: The Real Story On October 20, the Agile Cooperative will be hosting a free one-day...

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. 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...