Agile. A dirty word or a methodology for quicker, faster and better development? Depends who you ask. Recently I was told by a new client to not use the word Agile. I was shocked! Everyone likes Agile now a day. I said – “ok, waterfall is fine, we can do that.” The client then said – “no, I want to use Agile, I just don’t want to use the word anymore.” Turns out there was a little back and forth going on between multiple consulting groups on Agile methodologies. The purest were building the requirements. But, the development team was using their own processes. A few months went by and the client came to me and asked why I thought the project was failing. I asked – “can I use the word Agile.”. The client said “ok.” So, I explained the teams claim they are using Agile, but they really aren’t. Any process (Agile, Waterfall, etc.) won’t work if you don’t follow the basic rules. I explained that there are levels of rules you can follow, but there are basic rules that are necessary. Without the basic rules, Agile is a great excuse to skip necessary steps in the development process.

What is this post NOT? This post is not a discussion on how to create User Stories, what technology to use to organize a backlog, how to define points, etc. This post talks about the high level theories that are needed to make Agile successful. These are things we see skipped on projects many times. Don’t overlook the high level processes and ideas. They are very important to be successful.

  1. Just having daily Scrums is not Agile – Daily Scrums. An important aspect of most agile methodologies. 15 minute meetings everyday where the team talks about what they did, what they plan on doing and any roadblocks they have. These meetings are great. But, I see an issue in our industry. Lots of teams doing these meetings and saying they are Agile. This is just a small part of the larger Agile process. You are not Agile if you only do Scrum meetings!
  2. Client is King (or Queen) – the client (or product owner) must be at the meetings. This is very important. I see a trend where companies are doing internal Scrums or Backlog grooming sessions. Then, doing status meetings with the client to go over the decisions. I ask – Why? Why have extra meetings. Agile is supposed to reduce status meetings. It is built to improve visibility. Invite your clients. Invite your product owners. If they don’t “want” to show up, that’s a different story. At that point you have to get creative and find other ways to get your client this information. It’s your job to explain to your client (or product owner) the advantage of them hearing information early in the process to reduce confusion on business goals or requirements. This reduces overall timing on project immensely.
  3. Define your roles correctly – I recently had a project where the incumbent consultants said their architect is the Product Owner and the same person was the Scrum Master. What? The client has to be the Product Owner. Not the consultant Architect. The Product Owner is the voice of the business (or client). And, the Scrum Master must be impartial. The Scrum Master job is to be the intermediary between the teams. They cannot be in a role that makes they jaded. Their primary job is to take roadblocks to the appropriate person in order to allow the subject matter expert resolve. If the development team has a requirement question, the Scrum Master goes to the business and gets an answer on the question. If the business team doesn’t think something is being developed to the spec, the Scrum Master goes to the developer and works with them to make sure everything is clear. But, if the Scrum Master is an Architect, Product Owner or any other role that is already jaded because of their internal knowledge of the system, it doesn’t work. They end up guessing the answer based on their knowledge instead of asking the subject matter experts. The point is – regardless of the process you use, please understand the roles and who should do the roles. At first, this might seem like a small part of the Agile process. But, “who” defines each role is VERY important to the Agile process. Don’t overlook this!
  4. Meetings – meetings, meetings, meetings. It’s a fine line of too many verse not enough. I am a fan of reducing meetings. Why have weekly status meetings? If the client is at the Scrum meeting, they should be regularly kept up to date. Why have demo meetings within the Sprint? The Sprint should only be 2 – 4 weeks, demos should be at the end. Here are some of the basic meetings I think an Agile team needs to follow:
    • Daily Scrum: 15 minute meeting for A QUICK check-in. Developers talk about what they completed, what they intend to work on, and any impediments they have. The Scrum Master lists the impediments for resolution. This is typically not a meeting that actions are take. It is a daily status check to make sure everything is “OK”. The Scrum Master then takes the impediments for resolution. The rest of the team gets back to work.
      Attendees: Entire Team (client/product owner highly encouraged to come).
    • Sprint Planning: 1 to 2 hour meeting at the beginning of a Sprint to discuss what items are included for development in the upcoming sprint and verify that the acceptance criteria are clear. Attendees: Entire Team
    • Impediment Resolution: as needed meeting to resolve a particular impediment. Attendees: All team members required to solve issue
    • Backlog Grooming: 1 to 2 hour meeting AS NEEDED. Holding these meetings is a balance. It is critical for the attendance list to be correct and only have required team members. Team members can be working on other issues if they are not required for the meeting. The purpose is to decompose/define user stories. This is where functionality and acceptance criteria are discussed and logged into user stories. The developers also make their technical recommendations for implementation etc.. It is best to have an agenda for these. With an agenda, required team members can be determined and non-required team members can continue working on priority items. It is best not to add items for discussion during the meeting, as the team does not have time to adequately prepare. Backlog Grooming is VERY important for Agile development. Keeping the correct backlog items, the correct acceptance criteria and the correct priority is very important for an Agile project. The Project Managers, requirement analyst, product owners and clients should plan to be part of these in order to have the best backlog possible.
    • Sprint Retrospective: half an hour meeting at the end of a Sprint to discuss process. Decide as a team what went well and what needs improvement. Agree on process changes that need to be made. These changes take effect during the next sprint. Attendees: Entire Team
    • Story Demonstration: 2 hour meeting for the team to demonstrate completed functionality. This is traditionally done utilizing a side-by-side comparison of the user stories and the working integrated product. The team compares the acceptance criteria to the demo and the Product Owners determine if the functionality meets the acceptance criteria. The meeting also serves as a status meeting, as all completed stories should be demonstrated. For all of the outstanding stories, an explanation for non-completion is given and a path forward decided upon.
      Attendees: Entire Team – Developers can come in and out as needed.
  5. Project Plan: What? A project plan. Isn’t that waterfall? No, it isn’t. Keeping track of Sprints, demos, milestones, etc. is very important in Agile. Be careful to incorporate your meetings into the plan. I’ve seen Agile plans that just say “3 week Sprints”. Well, how much of that is development time? How much is testing? How much is demos and retrospectives? Keep all this in mind when creating your plans.
  6. User Story Completion – it’s called different things with different processes. User Stories, Features, etc. Regardless what you call it, complete it! Sounds simple. Complete one thing before moving to the next. If you don’t finish it in a Sprint, move it to the next. But, don’t remove criteria from it, call it complete and re-write a new User Story for the next Sprint. You’d think this is obvious. But, human nature does not want to admit failure. We are wired to mark things as complete if we estimated they can be completed in a certain amount of time. However, this is not always possible. Estimations are just that – estimates. We can’t always complete them in that time. Don’t feel that you have to each Sprint. It is your goal, but not a requirement. Move the User Story to the next Sprint, re-estimate and move forward. Believe me, it helps so much. Otherwise you will confuse your clients/stakeholders of what is actually left to do if you start creating new User Stories just so you can mark an old one as complete.

The above list are some high level things to do in order to organize Agile processes. It is not extensive. There are lots more things to do. But, it helps think through some things missed a lot. However, I employ you to understand the basic principles of Agile. Agreeing on the following principles helps you think through if you are doing Agile right or not:

  • Active User Involvement is Imperative
  • Requirements evolve, but timeline is fixed
  • Capture requirements at high level. Use backlog grooming to further define during Sprints
  • Develop small, incremental releases and iterate
  • Focus on Frequent Delivery of the Product
  • Complete each feature before moving to the next
  • Integrate testing throughout the project lifestyle (each Sprint)
  • Collaborate with ENTIRE team (including clients and stakeholders). It’s essential.