New to agile? Keep it very simple

Bob Hartman 2009-10-06
27 Comments
Post Views: 328

When dealing with an agile implementation, particularly in the case of a new agile team, we often make things too complex and difficult.  We tend to keep putting band-aids on the process until we have something that is overly burdensome and no longer useful.  I’ve now seen enough of this to know there needs to be an intervention!  So take a deep breath, relax and read how to simplify your life on an agile team.

The starting point is the 6 basic principles of what I call “Simple Agile.”  I mentioned I was going to be doing a talk for Agile Denver on this topic and I would follow-up with another blog post about the specifics, so here it is:

6 Principles of Simple Agile

  1. Collaborate
  2. Work together
  3. Honor priorities
  4. Respect the customer, the process, the product, the team and each other
  5. Do the simplest thing that works – then stop
  6. Improve every iteration.

Let’s take them one at a time, but very quickly.  I’ll probably write more about each of these in a future blog entry.  Be sure to leave comments or questions if you want further clarification of any of them.

1. Collaborate

Very simply, “collaborate” to me means to communicate effectively with each other.  There is no place on an agile team for a lack of communication.  Communication needs to be as near to real-time as possible, and hopefully as high bandwidth as possible.  In rare cases people on the team may not choose to use the best communication method available, but that should be the exception not the rule.

2. Work together

If we communicate well then we need to follow it up by working together.  For example, a Product Owner, tester and developer have all agreed on what a specific story means.  This does not imply the tester and developer go off their separate ways.  Work closely together to make sure the shared understanding stays shared.  I’m not sure what to call this other than “pairing.”  I’m also in favor of pair programming for a lot of reasons.  It has been proven pair programming signficantly increases product quality without affecting productivity.

3. Honor priorities

Always, always, always work from a RANKED product backlog.  You must work on things in the order they appear in the backlog unless there are exceptional circumstances (like a story is too big to fit in the iteration so it is deferred until the next iteration in favor of a smaller story now).  Everyone should follow the rule “the next thing you do should be a task in the highest priority story you can work on.”  This implies more than one person will work on a story (swarming).  It should also mean teams have fewer open stories (limiting work-in-progress).  This will lead to delivering the maximum value every iteration.

4. Respect the customer, the process, the product, the team and each other

When does a customer know exactly what they want?  When they see it of course!  When do they know how they feel about your product?  When they see it.  Let them see it more often, gather feedback and utilize the feedback.  Respect the process by sticking to it and holding each other accountable for process success.  Respect the product by reducing complexity and technical debt.  Respect the team by not having unrealistic goals, being sustainable and letting them solve their own problems.  Respect each other by working together toward success and supporting each other at all times.  I could go on and on with this topic (it is a personal pet peeve), but I won’t.  If you get a chance, do the following exercise: On a piece of paper write down all the different ways respect of these things could be improved, and next to each write down a list of the downstream effects such a change would have.  You’ll be amazed how much difference this can make toward success.

5. Do the simplest thing that works – then stop

Everyone in the product development industry has a tendency to do too much with every feature.  We even have a name for it: goldplating.  It is very easy to fall into doing it.  Ever hear something like “While I was in the area I did XYZ.” or how about “The story didn’t say to do this, but I knew the user would want it so I did it.”  Both statements should never be heard on agile teams.  We should do the simplest thing that works – then stop.  Ask the customer (remember we are respecting them by getting them involved) if we hit the mark.

6. Improve every iteration

Remember, 1% better every 2-week iteration will make a team more than 25% better after a year.  Big improvements aren’t needed, just a lot of small ones.  This might be the most key principle of “Simple Agile” because it enables us to understand we will never be perfect.  Keep trying to get better and you will.

These 6 principles are designed to get teams back to thinking of what is important.  They draw heavily from the principles of lean software development.  In many ways they could be considered rewordings of those principles.  I believe in these principles.  I believe they make a huge difference when teams believe in them as well.  How many are you violating and what are you going to do to get back to doing the basics?

Until next time I’ll be Making Agile a Reality® by continuing to coach teams to do the basics well, then improve.

Here is a copy of the presentation I used at Agile Denver.  It doesn’t have a lot of detail, but feel free to use portions if they help get points across to your team.

Updated December 23, 2009: You can also see the presentation at SlideShare.

Categories: Agile Ideas, Lean, Newbie, Principles
Bob Hartman
Known as Agile Bob, brings over 35 years of experience and broad industry knowledge cultivated by serving in almost every role in the software industry including developer, tester, documentation writer, trainer, product manager, project manager, business analyst, senior software engineer, development manager and executive. Over the past 20+ years Bob has grown from being an early adopter of Agile to his current status as a Certified Scrum Trainer® (CST) and Certified Enterprise Coach℠ (CEC) and an expert in training, coaching and mentoring across all areas of Agile development. Bob is a popular speaker, having spoken at numerous major conferences, seminars, workshops and user group meetings where his engaging style, holistic view of development and personal anecdotes are always well received by attendees. See his upcoming courses by clicking on Upcoming Courses under Agile For All in the menu at the top of your screen.

Related Articles

Responses

  2. Phani Vankadari 2009-10-13

    Thanks for this wonderful blog post!!! Many of these aspects are respected and followed by my team … looking forward to getting these on the to-do list ASAP for the whole team.

  5. Jens Kramer 2009-11-21

    Thanks for the post. I totally agree. Especially customer inclusion is critical in order to get the software result customers are really demanding. Maybe there’s one important thing to add. Users have to be guided when they’re applying software. Guidance is e.g. realized by labels/wording, software flows or just less options on the screen. It’s crucial to crosscheck this after each iteration and not to bring complexitiy to the user interface: “Don’t make me think!”

  6. Arockiaraj Durairaj 2009-11-21

    It is much better to use a tool than expecting every body to follow the process strictly. In fact the inablity to find somebody is not following the process is the biggest killer of software processes.

  7. Will McNeice 2009-11-21

    I read Rule #1 and realized I was already violating it! Off to a bad start. At least by not having anyone else to work with, I can’t violate Rule #2. Seriously, these are good tips, and I love the fact that the post is short and to the point.

    1. Bob 2009-11-21

      But Will, even on a team of 1 you can collaborate more closely with the customer. While the blog post doesn’t explicitly mention it, that is definitely one of the big areas people forget about. I have no idea how to be agile without being closely involved with the customer, but people keep trying it!

      Thanks for giving me an idea for a blog posting though. I am a team of one myself (my business really) and I use agile concepts throughout my life to make it all work. I probably should post some ideas on that. Hmmm….

  8. Vijay Narayanan 2009-11-21

    Bob-loved this post!! really liked principle 3-honoring priorities. It is important to align the iteration goals with what our business stakeholders consider priority. As you have pointed out, helps deliver value iteration after iteration.

  9. Vijay Narayanan 2009-11-21

    Bob-loved this post!! really liked principle 3-honoring priorities. It is important to align the iteration goals with what our business stakeholders consider priority. As you have pointed out, helps deliver value iteration after iteration.

  10. Tobias Mayer 2009-11-26

    A wonderfully simple and clear description of how to start being Agile. Thanks for that. I especially liked “1% better every 2-week iteration will make a team more than 25% better after a year.” Powerful statement. I’m bookmarking this page 🙂

  12. Amit 2009-11-30

    Bob,

    A very simple but yet very effective post!!! Really liked it.

    Rule #4 – important aspects as there are so many things we thought of but which are not there in the story, and we try to relate them to end user. Need to avoid this!!

    Looking forward for more though!!! My thirst has not gone!!!!

    Best Regards,

    Amit

    testing is my passion!!!
    http://bugteaser.blogspot.com

  13. Amit 2009-11-30

    Bob,

    A very simple but yet very effective post!!! Really liked it.

    Rule #4 – important aspects as there are so many things we thought of but which are not there in the story, and we try to relate them to end user. Need to avoid this!!

    Looking forward for more though!!! My thirst has not gone!!!!

    Best Regards,

    Amit

    testing is my passion!!!
    http://bugteaser.blogspot.com

  26. Mark Michael 2020-06-30

    I do agree, keep it as simple as possible. Beginnings are difficult enough, don’t make them more like that. What helped me when I started my journey with Agile, was a very simple tool we (as a team of 4 then) used – just a kanban board like https://kanbantool.com/kanban-guide/kanban-board . After all these years we still use it for some of the projects so I think it’s very useful to know as many tools as you can.

Report

Harassment or bullying behavior
Contains mature or sensitive content
Contains misleading or false information
Contains abusive or derogatory content
Contains spam, fake content or potential malware

Block Member?

Please confirm you want to block this member.

You will no longer be able to:

  • See blocked member's posts
  • Mention this member in posts
  • Invite this member to groups

Please allow a few minutes for this process to complete.

Report

You have already reported this .