Tag: process

Categories
Agile

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.

Categories
Agile

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 🙂

Categories
Agile

Agile: The Story Board

The story board…

If you have used Agile for Project Management or Software Development, and used Scrum, you probably have heard of the “Story Board”.

Trek BI Agile Story Board

Funny thing though, I have talked to a few people that have came through and they saw the boards we have and it was “oohh I have never seen one in real life”.. but yet they have run or been involved with scrum before.

So what is the deal with the “board”?

  • The Board is a focal/gathering point
    Every day at your standup/scrums, you should bring the board in and use it as a tool. Also at the sprint planning. Think of it as another team member. Talk to it. Talk in front of it, analyze it, adjust it, show it off, explain things on it to people
  • The Board shows tangible evidence of results
    You should hang your velocity and burndown charts on the board, you should have a nice full current and next sprint that changes every day as people do things and new items get prioritized. Your backlog should be filling up. Communicate your iteration dates and maybe other key info, but most important, if someone walks up, they can see your burndown.
  • The Board is a talking point
    People around the office start asking “What is that thing?” People in other teams want to know what is up. Other people might come up and ask where things are at, or where their “story” might be. You can use the board to start discussions on agile and also about your project
  • The Board let’s your focus
    As a developer or “do’er” for your project, you can focus on just the current sprint. You can focus on the cards on the board. You see slightly what might be coming in next sprint, but you are focused. As a product owner or team lead, you can see progress and focus on the current 2 weeks.
  • The Board makes it tough for distributed teams
    If your team has some members off site part of whole of the time, then it is harder for them to actually “use” the board. They need a virtual board as well. They need virtual stories or some way to update progress.
  • The Board adds a little overhead for Scrum Masters
    With a online system or virtual system, the Scrum master can update things there, and so can the developers. With a board, and especially with a board + virtual system, the scrum master has to make sure things are in sync. What should they focus on? The board or the virtual system? Both. But since the board is visible to EVERYONE who might walk by, they need to make sure it is up to date and in working order.

My thoughts: The board *should* exist, you *should* use a board.

But, what if you run distributed teams? Then.. if majority of them are not on site, then use a virtual board. If it is a mix, use a physical and virtual board.

But what if we don’t have room for a board? Then make room.

But a board costs money. Not really. I made one out of things lying around the office. Minimal cost. You can expense story cards, etc.

But xyz.. well, I am sure there is an answer.

If anything, start with a board, and cards (another blog post on that) for at least one year, and then look at going virtual, *if it makes sense*. I still think the use of the physical board is a key part of the process, but like with anything Agile, the process always differs by team and project.

You can always roll the board somewhere to demo. You can show the board to anyone. Any worker, any executive, a group of many people, or small. You might not be able to do that with a virtual system: you might be limited by number of accounts or other system limitations.

The board might be a “relic” of agile, but I think it lends itself to running the process in a way many can understand, without having to learn any software, and also lets your team communicate progress and results easily. Use a board? Just do it.