Tag: Project Management

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: 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

Categories
Agile

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. Retrospective – 15-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.


Categories
Agile

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.


Categories
Agile

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.

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: 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”

Categories
Agile

Agile: Sprint

The sprint. The timeline of an agile team. The sprint is the “timebox” that you use to get your stuff done. It’s an iteration as you want to keep having sprints over and over.

You might have many sprints make up a release, you might have one sprint make up a release.

Your sprint could be a number of different timeframes.

I suggest 2 weeks.

Why 2 weeks? Well, it is enough time to get things done, but not have too much to worry about, it also ensures that things you want to get done are done in a small enough time frame so that the people that needs to see your outputs don’t have to wait longer than 2 weeks. 2 weeks also fits nice as 4 weeks could almost be considered 1 month.

Other alternatives? 3 weeks – might be the only other time frame I would suggest using, but then remember, if you have something get requested before a sprint, and you can’t get it into the current sprint, you won’t see that story completed for 6 weeks!

1 week is too short, you are just constantly churning. 4 weeks is another one that some teams use, but again, it could be 8 weeks before seeing something. The world just moves to fast for that kind of timeline.

Other options are doing staggered sprints. 2 2 3 2 2, or 2 3 2 3 2, etc. It can get confusing, but doable, I haven’t seen a reason to do it yet, so I have kept to the 2 week timebox.

I also recommend starting on a Tuesday, Wednesday, or Thursday. If you run your sprints say, from Tuesday, 2 weeks, you end up ending on a Tuesday afternoon. Same with Wed/Thurs. And you can do your Sprint Planning on that Tuesday/Wednesday/Thursday. When you use Friday and Monday, things just get tough to plan around. You probably never want to release on a Friday, people like to take vacations and days off on Fridays, tec.

Another tip, don’t treat a sprint like a mini-waterfall project. You will end up in trouble. Try to test/validate completed stories as they get completed by the do’ers. Waiting until the end of a sprint will lead to pile up of things to do.

Throughout the sprint, the product owners and requester of features should be in the loop (for one, with the Daily standup) but also they should be seeing the fruits of your do’ers labor, they should be seeing the output and features as they are completed.

Releasing at the end of the sprint is key. If you can’t, then you should at least have things in a “potentially shippable” state so you can demo and test it for the people that have requested it.

Other things you can do with your sprints. I like to separate out things into their own “mini sprint” when needed. An example might be, Upgrading your infrastructure to SQL Server 2008. You can’t really work on things on your servers when they are being upgraded, so at the end of a sprint, say “the next week is a mini sprint for the upgrade” and then pick up your regular sprint schedule after that. Same thing with holidays. Over the Christmas and New Year holiday you may have a 2 week holiday sprint. Just let your do’ers do research or something fun they have wanted to do. Most people will be out of vacation anyways.

Treat your sprint though like you would treat your daily standup. You don’t (you really can’t – or it screws up things) want to keep adjusting your days and length very often. The more you adjust the more it confuses people and the harder it is to try to get your actual velocity.

Pick a date to start, pick a timeframe, and stick with it. Try to stick with it for a year, at least 6 months before totally changing things up. Discipline, just like the daily 15 minute standups. Keeping things standardized and set helps your team and others know the schedule and keep things on track.


Categories
Agile

Agile: Daily Standup, Daily Scrum

I hate meetings. Really, I do. They are toxic.

But one of the things your team needs to do is meet daily. With agile, it’s called the daily standup or daily scrum meeting. But what is it?

  • Every Day, 15 minutes
    The meeting needs to be every day. Every day (Monday-Friday). No Exceptions. No days off, no skipping, no excuses. Schedule it every day. 15 minutes. Try to get it in the same place
  • Stand up
    The reason it is called a “standup” meeting is that you need to actually stand up. Why? Because sitting down makes people take their time. Standing up makes people move faster, because they don’t want to stand for 60 minutes.
  • Three Questions
    What I did yesterday? What am I doing today? What’s in my way? Simple enough
  • Not Everyone
    You want your do’ers there, you want the scrum master and product owner, maybe some others, but not everyone needs to talk. Go around the room and the do’ers should give an update, others should just listen.
  • Details, but not too much
    Do’ers, when giving updates, should let team know what stories they are working on. If you use a virtual+physical board, you will have story #’s. Don’t just spout the numbers. Spout the numbers and the story title, and where you are at, maybe even burndown if you track that manually.
  • Keep on Track
    easy to get off track. Even with standing and whatever. Scrum master should make sure things keep moving. In, update, out, go. 15 minutes? Try to get done in 10.

Should you meet on your sprint planning day? I say yes.

What else does the daily standup bring us? Communication. Everyone should know what everyone else is working on, where things are at. People can’t hide. They need to give updates, they probably should have a good reason or be working on something else off sprint if they have no update.

What else does it bring? In my eyes: Discipline. Making sure you know what you did, what you are doing, and always meeting at the same time, and doing the same thing every day brings a little discipline to the team. Keeping things on track, 15 minutes, cruising through updates, instead of meeting speak and 60 minutes of babbling. It does good for everyone. It lets your do’ers get on with their day so they can keep burning down points!


Categories
Agile

Agile: Stories

In Agile, there is the concept of “stories” or “User Stories”. What are stories? Well, maybe it is best to look at what they aren’t:

  • They aren’t projects
    Stories are smaller than projects, by a long shot. A group of related stories is called an “Epic” but even then an “Epic” isn’t a project. But again, it all depends on how you or your organization defines a “project”. An agile team can focus on one project throughout their entire lifetime. Another might work on multiple projects, it all depends on how things are set up. But stories aren’t projects. Projects are made up of stories.
  • They aren’t tasks
    Stories should be bigger than tasks. Each story should really take a few to many tasks to complete. You can get into the mindset of breaking up everything into tasks, but then you might be going to granular. You want your stories to be small enough to get completed within your sprint, but also big enough to not take 10 minutes to complete.
  • They aren’t direct requests
    What do I mean by direct requests? A direct request from and end user or customer doesn’t directly relate to a story, it usually ends up being multiple stories. In the case where the request is just one story, it probably should be reworked to fit the mold of a story.
  • They aren’t features
    They might be feature requests, but like “direct” requests, usually a feature request ends up being multiple stories, or if the request is small enough to be one story, it needs to be reworked to become a story.
  • They aren’t bugs
    same as direct requests and features.
  • They aren’t day to day operational actions
    Some people might get into the mode of “well, we do this every day, so it should be a story”. No… it shouldn’t. It should be what you do day to day. Your velocity will get adjusted by your do’ers doing things day to day, but you shouldn’t storyize day to day things. Would you create a story for your commute? For reading email? For lunch? The only thing you might want to storyize is an architecture type meeting, where the deliverable is a bunch of stories. I like the idea but I’m not 100% sold on it yet.

Well, so there is a short list of things stories aren’t. So what are they?

As a user/group/xyz, I would like new feature/bug fixed/thing done, for this reason/business value.

I would say the most key part of that story format is the end. The business value. Without that you are spinning your wheels, you don’t know why you are doing something.

What about things that go along with a story?

You might write the # of a record in your virtual system to easily correlate. Depending on your process, you might hand write cards (I personally like this method). Or you might print them. What about other notes? As a developer or do’er you might write things on the back of the card for when you pass to QA or the validation of the story, or just to keep things in the open. If you use a virtual system, you might have extra notes or background info so the do’er can actually do it.

I like to have a small title, and then the story.

Example,

As a sales executive, I would like to be able to see my sales and goals by product and year so I can better analyze my commissions.

A title might be “Adding goals/sales to cube for sales”

I also like to have a “component” when working on a team with multiple mini projects that might be getting done. “Sales Cube” might be a good component for the story above.

What else do stories have? Priorities and Scores. More on that later..