Agile Practitioners Aren’t Supposed to Use Flamethrowers – Are They?

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: [Read more...]

Agile pondering: Why use an agile approach?

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. [Read more...]

Agile antipattern: Doing Agile!

successladderI 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. [Read more...]

Free Event! Agile Adoption: The Real Story

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!

New to agile? What does the ScrumMaster do anyway?

ScrumMaster_CertificationI 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! [Read more...]

Agile antipattern: Working overtime

working_overtimeEver 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! [Read more...]

New to agile? What to do when you are behind

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! [Read more...]

Agile antipattern: Insanity! (5 insanity antipatterns)

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! [Read more...]

Agile antipattern: Treating symptoms not causes

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. [Read more...]

New to Agile? Use a Rules of Engagement document.

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… [Read more...]