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.

The theme of the blog this month is “Getting a Fresh Start.”  In order to get a fresh start it is important to know WHY you want to do it!  I’ve seen many presentations over the years about why agile is something a software development organization should use.  I’ve seen this sort of presentation called “The Business Case for Agility” and several other names.  I’ve seen people walk out of those presentations, go back to their organizations, implement agile – and fail miserably.  Clearly having a reason for using agile is not the only important thing.  I think many of these presentations are presenting some possible reasons for using agile, but they sometimes miss a key point – WHY are those reasons important.  In the spirit of Agile For All’s second agile belief, I’m going to try to explain WHY some of the popular reasons are important to consider.

Know why, not just how. Too many people are learning the “hows” of agile and not the “whys” that drive successful process. This causes much more failure than is necessary. We always teach whys and not just hows.

Having worked with clients that range from very small to very large I’ve observed an unusual trend.  Each client believes their problems and issues are unique because of their corporate culture, industry, people or something else.

However, I’ve also observed another unusual trend which goes directly against the first one.  Most of the time my clients are wrong in the belief they are unique!  Certainly there are some differences.  That has to be true or every company would be identical.  Many times even the ways the problems manifest themselves are different.  I know that sounds strange.  How can the problems be different if I just said the problems aren’t unique?  I’m not looking at the problems, I’m looking at the CAUSES!  The underlying causes are the same or very similar but the way those causes manifest as problems may be different!

Below are 5 of the popular reasons given for switching to agile (and one extra I added because I could).  I’ve added the problems typically addressed, but I’ve also added some underlying causes and WHY an organization would might see those results and want to address them.

This list is FAR from exhaustive.  I am sure there are 20-30 items in causes I have not listed.  I just wanted to make the point that the obvious problems being “solved” by agile actually trace back to potential issues which may are may not be directly addressed by an agile process.  For example, will organization structure be addressed by switching to agile?  Probably not, but it WILL be exposed as an issue if agile is done properly.  Organizations need to be prepared for 2 possibilities for each problem: 1) it is caused by agile, or 2) it is exposed by agile.  Most problems will be of type 2 and very few will be of type 1.  Some things may be caused by agile, such as the stress it causes as teams get used to meeting iteration deadlines.   However, most problems will be of type 2.  Are you ready to admit it and deal with those as they are exposed??? [note, this technique is based on a blog entry by Vikrama Dhiman where even more details for a good retrospective can be found]

I know the table above has a LOT of entries in it.  If you don’t understand one please leave a comment and I’ll try to clarify it.

Are you depressed now?  Don’t be.  Agile really can help solve most of those problems simply by exposing them!  It is often too easy to hide the elephant in the room.  Get it exposed then deal with it and your organization will get better!

Until next time you should look at the list of causes and see how many fit your organization.  After doing that exercise maybe you should call (303-766-0917) or email me so I can help you in Making Agile a Reality^® for your organization!  I’ll offer 30 minutes of free agile or scrum coaching to the first 10 people who email me mentioning this blog entry.  The coaching will start out via email questions, but will include a phone conversation if necessary.  If your organization is struggling, let me help!

Related posts:

1. Agile pondering: How does a highly mobile agile team of 1 work? In my last post I gave you insight into how I do...
2. Agile Pondering: Who leads an agile team? On Saturday, April 11, I ran a PMI Mile Hi workshop I...
3. Agile pondering: How does agile work with a team of 1? See that picture off to the left?  That is me and my...

I spent the past week in Orlando, Florida  at the Agile Development Practices conference and I heard a number of people say “We do agile at our company.”  When pressed further it suddenly became “We do agile at our company except we don’t do …”  To me that sums up the problem of DOING agile versus BEING agile.  It is quite easy to DO agile.  You pick the non-threatening pieces and parts and simply do those.  Then you say you are doing agile and no one is the wiser.  Unfortunately, when pressed you have to admit to not quite doing agile very well.

Being agile is completely different.  Being agile means you understand the principles which lead to true agile success.  It also means the team and organization are both constantly improving.  When you are being agile daily standup meetings and retrospectives are both very important meetings which help the team be successful.  Finally, being agile means being unafraid of failure.  Doing agile has none of these qualities because it is all about doing the agile practices, not living the agile principles!

How do you go from doing agile to being agile?  You start by understanding the difference.  To be fair, most agile teams do agile rather than being agile so keep in mind you are not failing you probably just didn’t know something better is available.  Once you understand the difference you can start to rely on the process to self-correct you toward being agile.  For example, during the next retrospective ask why the daily standup meeting is a boring status meeting instead of a vibrant exchange of information which helps the team toward success.  Perhaps you can ask why the team keeps making the same mistake of not meeting the commitment made during iteration planning (maybe you need to go back to real basics and ask why iteration planning isn’t a commitment at all).  It may help to ask if the team is willing to be agile and work toward continuous improvement rather than continuous mediocrity.

Once the questions are asked the team should strive to find some action items which will help them get better in those areas.  If the team is truly dedicated to BEING agile rather than DOING agile they will find action items which they can commit to in order to improve.  This is the key first step to being agile.  Once you have a breakthrough in this area it is very easy to continue being more agile each iteration.

A journey of a thousand miles begins with the first step.  Is it in you and your team to take the first step to go down the path of BEING agile?

Until next time I’ll be Making Agile a Reality^® by helping teams BE agile!

This blog entry first appeared as an article in the November 15, 2009 edition of the Weekly PM Insights newsletter.

Related posts:

1. Agile antipattern: Hiding unfortunate truths “Unfortunate truths” are things which are true – unfortunately!  I’ve heard the...
2. Agile antipattern: Treating symptoms not causes Agile teams often get to a point where they have a number...
3. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...

On October 20, the Agile Cooperative will be hosting a free one-day seminar designed to give attendees a lot of information about what is really required to be successful with an agile adoption.  If you are in the Denver area and your organization is giving any consideration to adopting agile you must attend this seminar!  We aren’t going to pull any punches.  We will be talking about real numbers, real needs and real chances for success.  Click HERE for more information and to register.

I certainly hope to see you on the 20th!

Related posts:

1. New to agile? Remember a user story is more than a card! What’s wrong with the user story on the card?  It seems to...
2. Real World Agile Testing with Fit and FitNesse Another short blog entry.  This time it is to announce that we’ll...
3. New to agile? What to do when you are behind Wow, has it really been more than a month since I posted...

I often have people ask me what a ScrumMaster does.  Interestingly, today it came up on a mailing list I read on a regular basis.  So, naturally that means it is time for a blog entry to talk about it!

I am a big believer in simplifying things, so let’s start with an overly simplistic definition for what the ScrumMaster does:

“A ScrumMaster removes impediments for the team”

It seems many people believe this to be the only thing a ScrumMaster does.  Maybe it was the way they were taught.  Maybe they misinterpreted something.  This is definitely not all a ScrumMaster does.  If it were, then a ScrumMaster could work with many teams at once.  While some do in fact work with multiple teams I agree with whoever said “A good ScrumMaster can work with multiple teams at once, a GREAT ScrumMaster will only work with one.”  In other words you can be successful working with more than one team as a ScrumMaster, but it won’t be possible for you or the team to reach greatness!

This definition is extraordinarily and unnecessarily narrow.  A great ScrumMaster can and should do so much more!  Let’s expand the definition a bit:

A ScrumMaster is a servant leader helping the team be accountable to themselves for the commitments they make

Hmm, a servant leader?  Accountability?  Commitments?  Uh oh, Houston, we have a problem!  Let’s take this one piece at a time:

is a servant leader - According to Wikipedia, in order to be a servant leader, you need to have to following qualities: listening, commitment to growth, foresight, and the ability to build community.  In addition there are several common characteristics of servant leaders including collaboration, trust, empathy, and the ethical use of power.  Notice in hear there is NO mention of management.  Let’s be very clear about one thing: leadership is NOT the same as management (see an earlier blog post on this topic)!  If the ScrumMaster doesn’t manage the team who does?  This is one of the beauties and difficulties of Scrum – the team is self-managing.  This leads us right into point 2…

helping the team be accountable to themselves – A team that is accountable to themselves implies they are managing themselves.  This is very important for agile teams in general.  Not having the ability to hold each other accountable causes friction.  Accountability is not micro-management.  It is the opposite.  It is the ability to EXPECT someone to do their work and if they don’t deliver, to hold them accountable and work together if necessary to improve the situation.  In most situations someone is given a task and then a task master of some sort continues to check progress.  Accountability means giving someone a task and expecting it to be completed unless an issue is raised.  Not doing this implies a person is not a team player which leads to lots of other problems.  Since we are talking about the ScrumMaster here let’s bring this full circle and focus on the word at the front of this piece – HELPING.  The ScrumMaster doesn’t do it, they help the team do it themselves.  HUGE DIFFERENCE!

for the commitments they make - Notice the ScrumMaster is not responsible for helping the team meet external commitments.  They are responsible for helping the team meet the commitments the team themselves made.  This may involve the team working as a cross-functional unit (breaking down silos).  It may involve significant collaboration among groups.  It may (and likely does) involve removing impediments (so this is where that came from!).  It may involve holding the team accountable to their commitment to the Scrum framework!  In the latter case this can often involve coaching the team in how Scrum works.  Finally, this may involve holding the team accountable to creating the highest value product possible (high value combined with high quality combined with high productivity).

How do you do all of this?  Well a good starting point is a checklist of things the ScrumMaster can look at and work on.  Michael James from Danube has an excellent ScrumMaster Checklist available for download.  I suggest downloading it and seeing how you are doing.  If you are a ScrumMaster are you up for the challenge of becoming a great one?

Now that I’ve said my part let me point you to the Scrum Guide available for free download from the Scrum Alliance website [update January 18, 2010 - the Scrum Alliance website now links to Scrum.org which hosts the Scrum Guide as published by Ken Schwaber, one of the original creators of Scrum].  In the Scrum Guide it states the ScrumMaster is one of three Scrum roles.  In addition it says:

“The ScrumMaster is responsible for ensuring that the Team adheres to Scrum values, practices, and rules. The ScrumMaster helps the Scrum Team and the organization adopt Scrum. The ScrumMaster teaches the Team by coaching and by leading it to be more productive and produce higher quality products. The ScrumMaster helps the Team understand and use self-management and cross-functionality. However, the ScrumMaster does not manage the team; the team is self-managing.”

I think my description is in line with this definition.  Good thing since I’m a Certified Scrum Coach!

Until next time I’ll be Making Agile a Reality^® by helping ScrumMasters recognize their full value to the team they help.

If you wish to become a Certified ScrumMaster be sure to sign up for one of our CSM courses at www.agileforall.com/csm.

Related posts:

1. The ScrumMaster Diaries: #3 – Becoming a CSM Dear Diary, I completed day 1 of my 2-day Certified ScrumMaster course...
2. As a ScrumMaster silence can be golden! I love it when someone who was in one of my workshops...
3. The ScrumMaster Diaries: #2 – Making the Case to Become a CSM Dear Diary, Tomorrow I am going in to speak to Henry about...

Ever feel like the guy over there to the left?  Yeah, me too.  Sorry to offend some people with my language, but working overtime really sucks.  I always felt it meant someone else’s bad planning meant I had to have a lousy day, night, weekend (maybe all 3 at once!).  For agile teams, working overtime is bad in so many ways it is hard to count them all.  This post isn’t meant to give ammunition for someone in the middle of a death march.  Once you are in a death march the organization has two choices: a) keep up the death march and pay whatever penalties come up aftward, or b) recognize the penalties may be larger than the benefit and change the objective to be reasonable.  For people on a death march, I’m sorry you are where you are right now, but this blog post won’t really help you.  This blog post is meant to help people on agile teams where overtime is starting to become more prevalent.  Those people need help – FAST!

I’m going to try to conserve some words and just lay out 5 of the biggest reasons why agile teams should not work overtime:

1. Overtime is not a sustainable condition.  The amount of time people spend at work is at all-time highs just based on regular work hours.  Increasing the number of working hours will cause disruption outside of work which will in turn disrupt work.  When this occurs people are present longer, but they aren’t working more.
2. Overtime does not increase productivity as much as it increases cost.  Many studies, in different industries, have shown overtime hours to be far less productive than normal working hours.  In fact, some studies show that after 9 hours of work productivity actually goes backwards due to a higher number of defects being introduced!
3. Working overtime causes severe morale problems.  I don’t think my feelings in the opening paragraph are any different than what most team members feel when they have to work overtime.  A friend of mine uses the phrase “your incompetent planning doesn’t change my capacity!”  Is there any greater detriment to morale than feeling you are working for people who can’t do their job?
4. Even when working overtime gets the job done it perverts the process enough to cause problems.  If a team has a velocity of 20 and then works a lot of overtime to get 25 points done what should they commit to for the next iteration?  Most teams say 25 and cause themselves to start getting into the overtime habit.  Other teams pick 20 and end up missing because they are worn out from the overtime effort.  By the way, the team trying to hit 25 while likely miss as well.
5. Is getting in the very last feature really worth it?  This goes back to the title of this blog post – remember we are talking about an AGILE team!  So they are working on things in priority order.  Is it really necessary to get the very last feature completed at the expense of killing the team?

In my opinion working overtime should only be done when the team feels it is necessary to meet a commitment THEY made (not commitments made by others and imposed on them) and are in danger of missing because they made other bad decisions along the way.  In this case I’m ok with people wanting to feel good about themselves by making up for their own mistakes.  In fact, I like that in teams.  It shows they have some pride in their work and they want to continue to be successful.  I can’t come up with another reason for overtime which makes sense to me when I really analyze it.  (I consider the “we’ll go out of business if we don’t work overtime” argument to be  red herring – some businesses should not succeed if they do it by treating everyone like dirt.)

Until next time I’ll be helping teams avoid overtime by making sure they understand planning at all levels of agile in order to make commitments which can be met without working overtime.  Doing this will ensure that long term they will be Making Agile a Reality^®.

Related posts:

1. Agile antipattern: Target fixation Have you ever been so focused on something that the rest of...
2. Agile antipattern: Comparing velocity between teams I recently saw an excellent blog post about iteration velocity.  Good reading...
3. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...

Wow, has it really been more than a month since I posted something on my blog?  Ouch!  I guess I’ve been busier than I thought.  I knew it had been a while, but I thought it was 2 weeks, not a month.  For those of you who expect content from me more often, I’m sorry.  I’ll try to get back on the 2-3 times per week train.

The good news is during my time away from blogging I found lots of new topics for future posts.  In the coming weeks you find postings on different estimation techniques, how the theory of constraints can help agile implementations, using kanban, and a whole lot of other interesting stuff.  If you have a topic you want me to cover, please email me using the link near my picture.  I’ll start on the blogging train with a quick post on what to do when you are behind!

Now, to make this post somewhat useful.  I’m obviously very behind on my blogging.  My personal goal is at least 2 postings per week so at this point I am about 8-10 postings behind where I want to be.  Since I do use the agile concepts I teach, I have to be transparent and admit it.  The first step to resolving the problem is to admit there is a problem!  This is also applicable to real projects.  You can’t mitigate risk, change priorities or adjust for issues unless you know the issues exist!  Transparency is a key agile concept.

So, what is the magic bullet for step 2?  There is none.  We’ve exposed the reality, now it is time to deal with the reality but we need to be reality-based with our solution.  In my case I could sit here and type that I will suddenly spit out 10 posts this week and catch up.  But even if I could do it, it wouldn’t serve the intended purpose.  I specifically chose 2 postings per week with 3 at the upper limit because I believe it lets people digest what I write.  If I suddenly pop out 10 postings in a few days people just won’t read or absorb them.  I want this blog to be a useful source of information, not something people avoid because there is “too much” content!  Again though, the same thing happens in real-world projects.  If a team is behind schedule they can sometimes pull off heroic efforts in order to get back on track.  Unfortunately, this often points out a bottleneck somewhere in their process which means all of the work won’t be absorbed properly.  Maybe they have some specific testing resources which won’t keep up, or the necessary environments will change too quickly to be used properly, or some downstream resource will be inundated with work which can’t be done faster than a certain rate.  In other words, it is very possible for the heroic effort to simply build a queue which can’t be squeezed through the system anyway.  The best approach here is to analyze what can be done and the impact it will have.  Heroic catch-up efforts are usually ill-fated for many reasons.  In my case, I’m not going to be heroic.  I’m not on a “real” project, so I have the option of just saying the past is what it is, I’ll adjust my velocity back to being 2 postings per week, and occasionally try to get out 3.

Then there is the follow-through phase.  Now that I have made the commitment, I need to follow through.  I’m in good shape so far because this blog entry counts as 1 of my 2 entries   For a real project a team may need to commit to more accountability.  If a new goal is set and the project is adjusted to allow for success then the team still needs to deliver on the expectations.  This is why the “fix” from the previous step needed to be reality-based.  It makes no sense to commit to something which is a fantasy.

Hopefully the transparency exposed the problem early.  Being reality-based allowed for a fix to be implemented which still can be considered a success.  And the follow-through will be done appropriately by everyone on the team.  If this occurs, then behing behind isn’t necessarily a bad thing.  It is better to expose it early than expose it late when there is no chance for correction except by moving the end date.

Until next time I’ll be Making Agile a Reality™ by helping teams recognize when they are behind and helping them understand and implement realistic solutions to their problems.

No related posts.

It is sometimes said the definition of insanity is doing the same thing over and over again and expecting a different result. This definition has been attributed to Ben Franklin and Albert Einstein, but research shows it is unlikely either originated it (there are many more instances on the web, I just referenced one).  In years past I modified the quote to say good developers test quite well, bad developers run the same code over and over again expecting it to pass at some point in the future!  I think we would all agree we try not to be insane.  Unfortunately, when it comes to agile implementations we can not only become insane, but we sometimes even try to defend the insanity!

Below are 5 common ways agile teams can be considered insane:

1. Never meeting iteration commitments – Too often teams overcommit for an iteration and carry work into the next iteration.  When this occurs on an infrequent basis it is probably no big deal, but too often teams do this quite frequently.  I covered this in a blog entry devoted to moving work to the next iteration.  But this behavior can also turn into the “extend the iteration” antipattern.  When teams don’t fall into one of those antipatterns they end up missing commitments regularly, which is the first of my 5 insanity antipatterns.  We can’t keep doing the same thing and expect a different result.  The team needs to understand they are missing their commitments and take action.  I hate to say this, but an agile team which does this too often starts to have credibility issues with management and may eventually find themselves unemployed!  To fix this pattern take the number of story points completed in an iteration and make that be the commitment for the next iteration.  If this continues to fail (ie, velocity continues to decrease) it may be time to consider using some Kanban principles like limiting work in progress (WIP).  Make a rule that no individual can have more than one task they are working on, and only X number of stories (where X is perhaps 1/2 the number of developers) can be in progress at once.  This will ensure everyone will be working together on completing stories before moving to the next one.
2. Testing late – This is probably the most common insanity antipattern for agile.  Teams continue to believe they can test after coding is completed and get good results.  This doesn’t work on large waterfall projects and it doesn’t work when turning an agile process into a mini-waterfall process instead.  This is often attempted by using the “code freeze during the iteration” antipattern.  Some teams avoid the code freeze but still try to jam in all the testing late in an iteration.  Testing should START by writing tests the first day of an iteration and tests should be run constantly as code evolves from nothing to being completed.  Remember, automation is your friend.  Dont’ fall into the “using manual tests” antipattern (unless the manual testing is for usability or exploratory purposes in which case it is warranted).
3. Poor estimating – Recently my friend (and fellow Agile Cooperative member) Richard Lawrence sent a “tweet” which was a quote from Eli Goldratt: “It’s better to be approximately correct than precisely incorrect.”  In almost every agile course I facilitate I ask the question of whether spending more time creating an estimate will make it be more accurate.  The answer so far has been NO every time I’ve asked.  I believe the students are correct, and Mike Cohn agrees with me in his books.  We tend to try to fix this antipattern by spending more time creating our estimates only to be wrong again and again.  This is going the wrong direction.  Teams need to get better at estimating by doing things differently.  I hope my blog entry “Ten Ways to Improve Your Planning Poker Results” will help.
4. Not trying to improve – I wish I could say this one is rare, but it is extremely prevalent among the “we started doing agile from what we learned in books and at conferences” crowd.  Although retrospectives are mentioned in books, for some reason it is rare to implement them as part of a new agile process.  I think this is probably because people think a retrospective is like a Lessons Learned meeting and are therefore useless.  Nothing could be further from the truth!  Retrospectives are a KEY component of a successful agile process.  A retrospective is the only time improvements can be made.  Start with “What did we do well?”  Then “What did we do less well?” and finally “How will we improve?”  Then move on to #5 below
5. Not assigning action items – Part of the reason Lessons Learned meetings don’t work is because action items are not assigned in order to make sure they get accomplished.  During each retrospective make an improvement plan consisting of a few items and assign people to make sure the actions are completed!  Without this sort of accountability no action plan will succeed.  Remember, this is a team commitment to improvement, so members of the team should be assigned.  It shouldn’t all fall on the Project Manager or Scrum Master.

In my opion, all of these items become insanity antipatterns when we do them more than once.  If we fail to learn our lesson then we have no one to blame but ourselves for the continued poor results.  If you see any of these antipatterns occurring then TAKE ACTION!  Make sure your team addresses the situation in a way which makes sense.  After all, continuing to do nothing is insane.

Until next time I’ll be helping teams keep their sanity by Making Agile a Reality™.

Related posts:

1. Agile antipattern: Comparing velocity between teams I recently saw an excellent blog post about iteration velocity.  Good reading...
2. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...
3. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...

Agile teams often get to a point where they have a number of problems which must be addressed.  During retrospectives these items keep coming up and not going away, so the team decides to try and fix the problems.  In order to do this the team starts by identifying a few tactics which they believe could resolve the issue.  Good teams will even decide to assign a person to the action items in order to keep the team accountable for actually doing the actions.

Do you see a problem with this technique of problem solving?  I do!  The team has identified symptoms and wants to resolve them, but they have done no root cause analysis.  In other words, unless they get lucky, they will only be putting a band-aid on the problem.

There are several techniques for getting to the root cause of a problem.  I’ll describe one which works reasonably well, and then describe another which has phenomenal results.  The first is usually called “The 5 Why’s Technique” or something similar.  This technique starts by asking why a particular effect happened.  Then no matter what the answer is, asking why that happened (2nd why).  This continues until “Why” has been asked 5 times, at which point you should have reached the root cause or be very close.  I took the following example straight from the Wikipedia link:

The following example demonstrates the basic process:

My car will not start. (the problem)

1. Why? – The battery is dead. (first why)
2. Why? – The alternator is not functioning. (second why)
3. Why? – The alternator belt has broken. (third why)
4. Why? – The alternator belt was well beyond its useful service life and has never been replaced. (fourth why)
5. Why? – I have not been maintaining my car according to the recommended service schedule. (fifth why, root cause)

As you can see, replacing the battery would not have fixed the entire problem.  Too often I find software teams asking “why?” only once, which will almost universally lead to a band-aid fix.  Asking “why?” 5 times can help, but it rarely shows the interdependence between problems.  It is a good method, but it is not the BEST method, and as readers of this blog know, I don’t accept mediocrity!

The image you see above is the cover of “It’s Not Luck” by Eli Goldratt.  The book is a novel which describes the Theory of Constraints Thinking Process.  This book, when applied properly, can be a catalyst for change which has incredible effect.  Unfortunately, the “when applied properly” clause of the previous sentence can really be a bother.  The Thinking Process is not complicated, but it is extremely difficult to do well.

When done properly it can take all undesireable effects (problems) and trace them back to a very small number of root causes.  Usually 10-15 problems can be traced back to 1-2 root causes.  Now instead of applying 10-15 band-aids you can focus on one single fix which changes everything for the better!  Imagine fixing 10-15 problems by addressing just 1 or 2 root causes.  Wouldn’t that be amazing?  The amount of time and effort saved is mind-boggling.

So, how does it work?  Well, that’s the secret sauce.  You can buy the book and figure it out from there.  Unfortunately, doing this from “inside” an organization is extremely difficult.  It is very hard to divorce yourself from the knowledge and preconceived notions you have about potential solutions.  You often will end up with the band-aid you expect if you are not extremely careful!

Fortunately, there is a better way.  Agile For All now offers a one day Agile Constraints Assessment Workshop.  For a very reasonable cost you can have myself and Richard Lawrence from Humanizing Work come to your location and facilitate the Thinking Process for you.  As outsiders we have no preconceived notions about your problems or potential solutions.  This allows us to facilitate the workshop so the process does the work rather than having everyone jump right to answers (which are usually incorrect or you wouldn’t need this!).  Over the course of the day we will help you understand the true goal of your organization, the problems you are encountering, how they relate to each other, the root causes, and most importantly a plan to effectively address the root causes.  If your organization or team wants to get better, let us help!  Also note, it is called an “Agile” constraints workshop, but that is really just marketing spin – the workshop will be effective for any type of organization, regardless of methodology or problems.

If you want further information on the Agile Constraints Assessment Workshop, please email info@agileforall.com.

Until next time I’ll be Making Agile a Reality™ for more teams by helping them identify and eliminate root causes of their problems!

Related posts:

1. Agile antipattern: Hiding unfortunate truths “Unfortunate truths” are things which are true – unfortunately!  I’ve heard the...
2. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
3. Agile antipattern: Burndown charts that hide the truth See that burndown chart over there to the left?  It looks beautiful...

How do we work together? Seems like a simple question, right? How wrong you could be!  For an agile team, working together is vitally important, but it is also the hardest thing to accomplish.  Why?  Because we don’t normally work together very well.  Think about the stereotypical high tech company and their sterile cubicles with “resources” working hard in isolation.  This is a far cry from the PEOPLE on an effective agile team who work in an open, collaboration friendly environment.  (In case you can’t tell, I have a pet peeve about calling people anything except people – in my opinion it is degrading to call people anything else)  But this isn’t the only problem…

Once we get the team working well together, we still have those pesky PEOPLE known as managers and executives that want to pry into every little detail.  Sorry, but that isn’t very agile, so wouldn’t it be nice if we could keep them from doing it?  What about the product people constantly changing the focus of the team on a day to day basis?  Or how about fixing the problem of the development manager constantly trying to tell the team they can do more work than is possible?  All of these things and many more come into play when we talk about the seemingly simple question “How do we work together?”

Because all of these things add up in a hurry, I encourage teams to put together a rules of engagement document to make clear some of the most basic rules and interactions.  I do this in conjunction with having the team determine their definition of what “done” means.  Both of these items are completed prior to starting the first iteration.  For maximum effectiveness have the team, managers and executives all sign the document as a sort of contract among themselves.  Having executives sign the document is extremely empowering to the team and helps them recognize they have the full support of the organization to be successful!

Feel free to use my sample Rules of Engagement document for your team.  If you make changes, please leave a comment here so I can consider making your change to the master document I use when I train teams.  If you have questions about the document either leave a comment here or email me and I’ll try to get you an answer.  This way we all can learn and improve this document for the teams that will use it in the future.

Until next time I’ll make sure teams I train use a Rules of Engagement document because it provides a lot of help in Making Agile a Reality™ for an organization.

Related posts:

1. New to agile? Work at a sustainable pace Question:  Which is better: a) Working nights and weekends to meet iteration...
2. Agile antipattern: Changing the definition of done Ever see a burndown chart like the one to the left?  I’ve...
3. Are you agile – the Nokia test I’ve been helping lots of clients start new agile initiatives recently.  This...