I’m not a project manager, but…, part 2.

As I said before, I’m not a project manager in real life, but I like to say I can play one on TV. I know enough to get by and know enough to come up with plans, timelines, resources, etc, to give my projects life and get them to completion. It’s not a skill all sys admins have as it requires thinking outside of the technology box and figuring out how your projects and deployments can affect other groups and other people. I like puzzles and can usually think my way around problems, and I think it’s helped me with regards to this kind of thing.

The newest fad these days is Agile, with its terms like Daily Scrum, Sprints, Scrum Master, Demos, Reviews, User Stories, etc. If you happen to be on the job boards there’s a good chance that when you look at PM jobs you’ll see a ton that mention Agile and what that kind of experience. I know, because my wife is a real Project Manager :).

Agile doesn’t have a PM, though. Their term for it is Scrum Master, I guess because you manage all the “scrum” and have daily calls, burndown charts, stories, tasks, and etc.

You can get an official definition of Scrum off of Wiki, here: http://en.wikipedia.org/wiki/Agile_software_development. They have a Manifest and everything:

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto introduced the term in 2001.

The whole point of Agile and why management loves the idea of it is that you can releases out the door quicker. Let’s say you have a team of Java Developers (who all know how to develop Java, of course!) and you know you’ve got a release coming up in 3 months. With Agile you would come up with the high level deliverables and try to break those up into chunks called User Stories to make the work smaller and more manageable so that your developers can have something easy to develop against. Then you have to decide how quickly you want this work done. From my research the typical “sprints” are 2-4 weeks (a sprint is your turn around time to get a typical story done) although I’ve worked a place that did 1 week sprints, which don’t work very well in my opinion. You see, part of the problem with Agile is that it’s very top-heavy with meetings. You have to have daily meetings where you go around and every person has to say what they did yesterday, what they plan on getting done today, and any issues they’re having. Then you have to have a meeting that can last half a day where you plan all the stories you want to get done in your sprint. Then at the end of the sprint you have another half day meeting where everyone talks about or demos what they got done in the sprint. The shorter your sprints the more percentage amount of time you’re spending in meetings.

So a “User Story” or just “Story” is the term used to describe what you want to get out of your sprint or tasks. Let’s take our example of the release you want to get done in 3 months. Say your goal is to have your web site up and running. Your story might be in the format of:

“As a web developer, I want to have a finished website so that I can browse to it and give it to customers for them to order products”.

Note the 3 different parts of that Story: “As a…”. In your Stories, you need to do them from different perspectives so that everyone knows which direction you’re coming from. Another tack for this one might be “As a customer of XYZ Company, I want a website so that I can order products”.

The 2nd and 3rd parts are fairly obviously, it’s what you want and why you want them.

This story might be called your “Epic” Story, which simply means that it’s the very high level of what you want. You really don’t get requirements or needs or what it takes to get that done from that story, but then you can create sub-Stories such as “As a developer I need to get the requirements for product ordering on the web from a customer” or “As a Marketing Associate, I need a web site that advertises our products so that we can sell more”. As you can see, for this 3 month release cycle you could generate hundreds of stories. Most of which you won’t know on day 1, but as you go on and refine your products and requirements they can generate other stories that get to the nitty-gritty such as: “As a graphics designer I need to build the logo for the web site so that…”

The idea behind Agile is to do your best to break the work down into workable chunks so that everyone on your team can work on any task and throw their results in the pot. High-level stories are usually generated by the Product Owner (another Agile term, simply means the person who is requesting the product and probably providing all the requirements). Lower level stories that get done in the sprint are usually tasked out by the team in planning sessions. Then the results are demo-ed in your Retro session. The idea here is that if you have requirements to build a screen or web page, you can take it back to the Owner and team (even if it’s only GUI and doesn’t actually do anything yet) and see if they like it. If they don’t, you take it back, create a new story for it and re-work it. The example we had in training was that say the Owner said they wanted the color to be yellow, then after they saw it they wanted it purple. So next week you make it purple. Then they see purple and want it red… this can go on for as long as you let it. One of the major tenets of Agile (which I don’t agree with it at all), is that it’s cheaper to do re-work (and re-work, and re-work) than it is to just do it right the first time after planning things out using the Waterfall method.

Well that’s high-level Agile. I attempted to give it un-bias. Now for the bias 🙂

Let’s re-read that blurb from Wiki:

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto introduced the term in 2001.

Do you see the pieces I’ve bolded there? “Software development”. The first thing I tell people is that I’m NOT a Software Developer, and I definitely don'[t play one on TV. I’m a Systems Admin, Engineer, & Architect. Pick your flavor and that’s me. I might be asked to come in to a company and “migrate us from Exchange 2007 to Exchange 2010, on a new Active Directory Forest”. That’s a long term project requiring buying tons of software or writing scripts and coming up with plans for how to architect your new AD, your new Exchange DAG’s, how to migrate PC’s over, regular domain members, etc. Give me a day and I can have a 10 page document for how it affects your environment to do this project. We’d also need to discuss HA and DR options, decide how much of that we want to throw in the mix, etc.

Your ask (or your Epic User Story) might be an incredibly easy statement, but it generates tons of work depending on the size of your environment and might end up being a multi-year project.

In a case like this, do you imagine I’m going to use Waterfall, or am I going to use Agile? Waterfall, hands-down. There’s no room for error in a project like this. You can’t simply do a lot of work and push it out and then go, “but I wanted it green”. This is a project that needs to be very precise and leaves little room for error. It also needs to be planned out to the nines. If you don’t account for the fact that at some point you’ll need to ADMT your users over and hopefully you moved your SIDHistory and hopefully they can still access their resources on FileServerA… the first user you migrate will be a huge and colossal failure. Oh, and hopefully you didn’t forget about your Public Folders and Shared Mailboxes. How did you account for those? And what if your team only has 1 Exchange guy? You’re not really at a place where you can task a story out and let everyone on your team do the work. Plus, you’ve got a team of Windows Engineers. Maybe 2 Exchange guys, 2 SQL guys, 2 web guys. They all have very specialized skills and what admin wants to be a generalist who knows just a little bit about everything? That’s the guy who ends up not moving up the ladder and just isn’t specialized enough.

This post is already way longer than I wanted it to be, but I’ll just end it by saying that I think Agile has it’s place. For software developers. You have a team of Java developers (maybe with varying levels of skill, but you get the point) and they can all mostly do each other’s jobs. You have a team of Engineers and you probably have 1 guy who’s doing all the work on the project.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s