Tag Archives: Project Management

Agile: Projects vs Support

One big questions that comes up ALWAYS when doing Agile is: “How do we deal with support requests (or issues, or helpdesk or operations)?”

Well, the answer, as you figured, is … It Depends.

First, it depends on what kind of project or team you have. Are you Development? Or Business Intelligence? or Creative/Design? or Infrastructure? Or XYZ?

One thing to think of as well is how is your organization structured? I went into a dev group and the developers couldn’t get anything done because customer service/support was constantly hitting them up with issues. What do you expect to happen? Magic? You need a buffer. 2nd Level support. Filter the issues so that there is just a trickle into “3rd Level” or Development.

You could even assign one dev to “3rd Level” for a sprint and reduce their velocity. But it always depends on how much is coming though. You want to reduce, reduce, reduce the noise coming into developers. Buffer.

What happens when there are issues that NEED to be looked into (server down, etc, etc). Well. Your “do’ers” need to look into it. You may have to pull out stories if it takes too long. Reduce the velocity. That is just the way it goes. If support issues continually cause you to pull out stories and reduce velocity, you should assess your organization structure, and get a support structure in place.

Big thing with support is this: YOU NEED TO TRACK STUFF. I can’t stress this enough. Bottom line is I have rarely or if ever seen stuff tracked well. This is a killer for your process. Issues need to be tracked for multiple reasons. Why?

Well, let’s look at a scenario or two.

1. Customer Calls Support
2. They work on issue for hours but never track anything
3. They go to 2nd level with the issue but since they didn’t track anything, who knows what was done already and what was changed, etc
4. 2nd level fumbles around for 3-4 more hours doing the same thing, but again, not tracking anything.
5. The issue gets handed off to 3rd level and it is a complete mess since nothing was tracked.
6. In the end, the issue might route back to 2nd level or whatever
7. In the very end, nothing was tracked at all. Even a Category or Sub Category, who the issue was for, what system, how much time, who worked on it, etc.

Now look at that scenario and think if everything was tracked. What if you could pull in all your support issues and Pivot them, slice and dice, see trends. Well, then you can figure out what you need for resources. Pretty simple actually. But harder in reality. People start working on something and run around like crazy and not tracking anything. It is a big problem.

Back to our main problem. Projects vs Support. Another thing everything depends on is this: Who is prioritizing your work? It is a main driver on what you work on. Someone needs to make a decision and say “This is a support issue, do it NOW, or.. This is not an issue, do it LATER, or.. this is part of our project, do a STORY” or something like that.

If the person who should be your main prioritizer doesn’t buffer or learn how to say NO, then everything because #1 top priority and everything you try to accomplish from a project perspective is worthless. Your prioritizer (if it is the Product Owner, your Manager, the Project Manager, whatever) can learn to buffer, and only let through the extra critical support issues to work on now, then you can dedicate 90-95% of your teams time to project (agile) work.

I think the main question of Projets vs Support really throws people off when it comes to Agile. Some groups are doing nothing but support so they are in a death spiral. They need a 2nd level support structure, or hell, even a 1st level support structure.

Teams that are trying to do Agile but feeling the pain of too many support issues, well they need a 2nd level support buffer.

Teams that are doing Agile but have 1st/2nd level support that isn’t tracking a ton are in need of some process control. (more so for resource management than anything).

As you can see, there are always ways to do things no matter what situation your team might be in, but definitely something you need to asess and figure out before you jump into a process.

Advertisements

Agile: Epics

So most people are familiar with “projects”. Something you do, have an end goal, usually a budget, resources, plan, etc. Sometimes you have projects within projects. Like a good example may be thinking of the next version of Microsoft Windows as the main project and revamping solitaire for the next version as the “epic”. Your end goal is to keep your main project moving forward, and do stories that apply to that project, but you also might run into mini projects along the way that could cross over numerous sprints, and you want to “group” like/similar stories together to form an “epic”.

What is nice about epics is they still let you do your sprints, and stories as normal,but you have a more higher reaching goal to get a set of stories complete to complete your epic. It also lets you look back and then see how many stories and points you did toward that epic and understand the effort,etc that went to completing it.

Use epics to group stories together to form a common goal for a similar “thing”. It will let you say “let’s focus on the blah epic” and you can make sure you get that piece of functionality done and track it and see all those stories together in the end.

P.S. Blogged from my iPad

Agile: Sprint Planning Meeting

The “other” meeting in Agile/Scrum. The Sprint Planning. You already have your “daily standups” or scrums going, but you need to actually *plan* your sprints. Before you start doing agile, you need to have an initial sprint planning. Call this pre-agile process sprint Sprint Zero or Sprint 0, or whatever, but it is going to be different than the sprint plannings after it. Why? Well, first let’s look into the planning pieces.

Now, you can split parts of these up into different meetings, but I like to keep them all together.

1. Retrospective15-20 minutes where you go around the room and ask each person. What went good this sprint, what went bad? Places to improve, places to keep things as is, what did you learn, etc, etc.

2. Review/Demo – 1 hour to 2 hours of going through all the stories you have completed in the previous sprint, reviewing with the “business” or the rest of the team, or product owner, etc. People can ask questions, and just getting all eyes on things helps to maybe find something subtle that someone else might have missed, etc.

3. Planning – This is the meat and potatoes section of your Spring Planning Meeting. Here is where you score all your stories that you have to score for the next sprint, or stories that are unscored in the backlog. This section of the meeting could last 2, 3, 4-6 hours depending on how many stories you have

So why would Sprint Zero be different? Well because you are just starting agile, you don’t have a Retrospective or a Review, you just do planning. (A more in depth post on just the “Planning” section is forthcoming)

Once you have scored all your stories, you are ready to go. After you go through your sprint, and you are nearing the end, you want to have another Sprint Planning Meeting, to plan out the next sprint. You do this type of “sprint”-ly iteration.. well, forever, or as long as your project is going to last.

I have found that holding sprint planning meetings starting early in the morning are better than the afternoon, just because people are more alert.

Also, having a good remote viewing option, such as Goto Meeting is going to make any remote do’ers happy.

Having some food and snacks for the team always is good too. A larger room where it isn’t as cramped is going to be good. Stuffing everyone into a smaller room for 6+ hours could lead to some crabbines, as well as just sweatiness :)

Of course, the Scrum Master is going to facilitate the meeting, but you might have one person or multiple do’ers drive the review/demo.


Agile: Roles – Scrum Master

Funny title, of course. Everyone with no idea about Agile/Scrum always laughs when they hear the title. Scrum Master (or is it Scrummaster?) – What is that? What a goofy title?

Yeah, but it is what it is. You are probably trying to run some kind of Agile/Scrum process, and you need then a Scrum Master :)

But what does a Scrum Master do? Well a lot of it might depend on your process and team but here are a few things (there are probably a hundred more)..

  • Facilitate the Daily Standup/Scrum
    Each day when you meet for your 15 minute standup, the Scrum Master should make things start on time, and keep flowing, and make sure people are answering the 3 questions (What I do today? yesterday? What is in my way?). The Scrum Master should cut off people from going long, make sure things get tabled or moved to a hallway discussion instead of taking of everyones time.
  • Make sure the Burndown/Velocity is being tracked
    The charts! Of course, someone needs to make sure the metrics are being tracked and also displayed. Now depending on your team, it might just mean .. well, nothing but making sure do’ers are updating their burndown correctly. You might have virtual charts. But in some teams, you might need to print the charts for the board, or you might even need to add the burndown yourself depending on your process/system. Keeping track of these metrics is key. You want to keep people informed of your progress every day (at least for the burndown – I like to track velocity as a bullet chart for the sprint and update each day as well).
  • Get all the Stories Ready for Planning
    In some teams, the scrum master might be the only person doing this, in others there may be a group of analysts, etc. But the Scrum Master should be sure to have the stories ready for planning, to score and discuss. Your team probably has a backlog of bugs, features, enhancements, technical debt, and it should be prioritized, but the Scrum Master should be where the buck stops to make sure everything is in order for planning.
  • Facilitate Sprint Planning
    Just like facilitating the daily scrums, the Scrum Master should facilitate the “Sprintly” Sprint Planning meetings. Review, Retrospective, Scoring. Keeping things moving, being an observer but not really a decision maker – that is for the team to do.
  • Be the “Blocker” From Outside Distractions
    Once you start doing Agile, things change, sometimes they have to change dramatically. If your team of do’ers is 3rd level support, or even 1st level support, they are going to need a buffer or blocker from outside distractions. People wanting things now! and support calls and walk ups, and everything else you can think of. The Scrum Master should and needs to learn how to say “No” to everyone when needed. “No, we can’t do that now, but we can look at doing it next Sprint” or.. “No, we can’t look at this right away, but if we get ahead, we can pull it in.. maybe”, or “No, we (just flat out) aren’t doing this”
  • Work with Product Owner on Story Prioritization
    The Scrum Master needs to work with the Product Owner (another Role for another blog post) to get the stories in order, and prioritized. This should happen sometime a few days or week before the Sprint Planning so things can get organized without being rushed.
  • Drive the Process, Improve the Process
    As with everyone involved, the Scrum Master should try to improve the process along the way. There are always way to do things differently which might lead to things running smoother. Change the day of the planning? Print cards? Auto burndown? etc, etc. The Scrum Master should work with the team and Product Owner to help continuously improve the entire process, and the Scrum Master should be the driver of the current process. People have questions on the process? They should ask the Scrum Master.

As you can see, those are just a few of the things the Scrum Master needs to do to help the Agile/Scrum process along. Many times, teams don’t have someone that will take the bull by the horns and drive the process, step up to the role. Other times it is just apparent who the person should be, and in others, it is a well defined role.

The Scrum Master’s role is very important in the process, as much as the do’ers and the Product Owner and others..But they should be the ones that *own* the Agile process and help move things forward.


Agile: Retrospective

The retrospective. The cousin of the “postmortem”. Why not a postmortem? Because our project didn’t die. We want to reflect on what we did right, wrong, how we can improve, what did we learn.

What is the retrospective? I like to have a 15-20 minute section before “review” and “planning” in the Sprint Planning Meeting. Everyone goes around and says what can we do better? What did we do bad? What did I learn? Capture the thoughts and feelings of people and look back at the last retrospective and see what you did this sprint to improve on last sprint.

The hardest part of this “retro” seems to be 2 things, depending on team. Some teams find all the *bad* things and list them out. Some just find all the *good* things and list them out. You need to have a balance. Some things always go better, some worse, so put them out on the table.

If you don’t know where you came from, you don’t know where you are now, or where you are going.

Agile: Scoring

Once you have your stories defined and you are ready to “score” them, there are some things you need to keep in mind.

What scale are you going to use for scoring?

I use 1,2,3,5,8,11, and 13. Why? Well, that is just what we used when I started doing Agile, and it seems to work :) Fibonacci + 11. I know I probably should change it so it kind of goes along with the more mainstream numbers that some 3rd party tools and other people recommend. Maybe, someday :)

1 is the lowest, 13 the highest.

At first, the team has no idea what a 1 or 2 or 8 or anything is. It takes time. Over time the team gets a gut feel for what a 1 is, or a 3, or whatever.

Don’t equate points to time! No, a 1 isn’t an hour, or a day, or X. It is a 1.

What are points?

Well, I try to explain it as time, effort, complexity, outside factorness, craziness, etc, etc. You kind of have to bundle all those things up and say, yea, that is a 2. It is more than a 1, less than a 3. Each team is going to have a different meaning for what a 3 is.

During your sprint planning, what you want to do is give everybody a pack of “planning poker” cards so they can score as you go through stories. (There are also web apps for virtual teams, iPhone apps instead of using planning poker cards). As you get done reading the story, and answering any questions, the team should “score” – show their cards. If they are all the same – great! You have a winner.

If some are different, then you discuss or come to an agreement on why some do’ers think it should be higher or lower, and get a score at the end. Example? 6 devs, 4 say it is a 2, 1 says a 3 and 1 says 1, well, most say it is 2, do the other 2 devs agree? if so, you can mark it a 2. If not, you might discuss why. The one dev saying it is a 3 might say, “what about this an that” and then everyone realizes, oh yeah, it is more than 2, and you go with a 3.

What happens if you see 13’s?

What I try to do is say – if you score it a 13, then the story is too big, you should break it up into smaller stories. With that logic, you should never have a 13 on your board.

The biggest thing to remember is that the team is going to have to take a few sprints to get used to the scoring, and understand how stories fit into points. You ARE going to over and under score – it is just reality. But don’t adjust the scores during the sprint. Things just tend to work themselves out over time. What you can do is capture actuals at your retrospective and compare to what the original scores were. The team might get a better idea on what they should be scoring things then. Another thing to try is a scoring guide. After some time, you can say “every story we do that involves making a new button on a form is usually a 2” so then if you have a story like that, and the team scores it a 8, or they don’t know what to score it, you can look back at your guide and say -hey, we usually score these 2’s, so is a 2 ok?

Who scores?

This is a good question, who should score? My opinion? Just the do’ers. The scrum master shouldn’t score, and product owner/analysts shouldn’t score. Just the do’ers.

What do you do with the points/scores?

You track your daily burndown, and your “velocity” per sprint. More on that later.

Just remember, think of stories as being scored by points. Or bananas. Or stars. Just not hours :)

Agile: Bugs

Agile can make things work for your process, you can get a ton done, but one question everyone has is “What about bugs?” or “What about things that come up during the sprint?” Oh noes!! Agile can’t handle it.. Agile will fail us.. fear not..

  • If you can, wait till next sprint
    Of course, if you can wait, wait. Don’t interrupt the current sprint, don’t get in the way of your do’ers focus, wait on it, assess it, analyze it, verify it, validate it, make sure you understand it instead of jumping in quickly and screwing something else up. Most times unless it is a HUGE showstopper, you *can* wait.
  • If you must, handle it. Swap something out
    If you can’t wait, then you should swap something out. You can’t just keep adding things to the current sprint, you will overfill your capacity. You need to swap something out. If this is a critical bug, it must be more important than *something* on your current sprint (that you haven’t started yet). If you are near the end of the sprint, then wait till next sprint.
  • If not a bug, but a request – First Option
    if it isn’t a bug, but a high priority request, you know the ones, from the president or god or you know. Well, then the first thing you can do is go to that user and say “Hey, we can do this, but we are going to move something out of the sprint that you requested.” If they say “Hey, no way, I want it all done”, then you respond “That isn’t the way it works, you need to move something out to move something in, or you need to wait and see if we get ahead where we *might* be able to pull something in, is that acceptable?” and then you think to yourself “someday these users will learn to think farther out than 2 days in front of their face”
  • If not a bug, but a request – Second Option
    So if you get this “god” request that *must* be done, but the user doesn’t have any existing stories to pull out, well here is what you do. You need to find a comparable story from someone else to pull out, and then you have to get that person, and the requester together and ask “Hey person we already committed to, is it ok if this other guys request bumps you out of the queue/sprint?” and if the person is ok with it (they usually are) then you can swap, if not, well, tough luck to the late request, they need to wait. (You can see from this process you need to learn to say “No”.
  • Last Resort
    the last resort, and I hate this option, but it seems it usually is the one that gets done the most. You just do the request. You fit it in, you work late, you do something different or something else takes a hit. The person gets there request, but no one learns from the process, since they think they can still request anything at anytime and get something from you, instead of learning to plan out a bit.

I’m sure there are infinite permutations of things you can do and situations you need and will need to deal with. The above is just a broad look at some the more recurring situations.

What you can learn from Bugs or Requests that need to be done *now!* is this:

There is always a way to adjust and handle things. Nothing is written in concrete. “Responding to change over following a plan”