Musings of Jason Jones

Category Archives: Project Management

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.

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.

I went to school at Purdue and we did have to take a series of classes on the Systems Development Life Cycle. Back then it was just called SDLC and was an ongoing process of Analyze, Design, Implement, Test, and Evaluation. Then Evaluation could cycle back into Analysis. It’s a logical thought process for how to develop/deploy new systems or projects:

Purdue was good in that they taught us how to build systems, how to write the code, how to support the hardware, how to do the network, etc, etc. It was a very well rounded education and in your last year or so you picked your direction and went with it. I picked Systems Administration, and this was before learning how to use Windows was a matter of course. (I was the last year who had to learn COBOL for the programming language.) But they did give us a pretty good rundown of how to run projects and how to build things. Being logic-minded this came very natural to me and I’ve used it pretty extensively over the 14 years since.

I’ve run major projects at large companies doing implementations and migrations from existing technology, mainly through tools like MS Project and Visio. Everyone has their own way they use SDLC and one of the ways I’ve always used it (and seen it used) is to add a last step to go back and talk to your stakeholders periodically and go “Hey, you told us you wanted full redundancy for your mail servers. We’re doing X, Y, and Z and here’s how it does it. Does that meet the needs you were asking for?”.

NOT going back to the person who requested the project is a great way to ensure failure.

That being said, sometimes you have hard and fast requirements and your stakeholders truly don’t understand what they’re asking for. For example, one of my prior companies went through a rebranding process where we renamed the company and they wanted “everything” with the old name to be renamed. Of course, our internal AD domain was xyz.prv. You CAN technically rename a Windows domain, but who have you ever run into who thought that was a good idea?

We took the opportunity to go through a major re-architecture of the entire environment (globally), built out a whole new AD environment on what was then new technology (2008), putting everyone into a new global Exchange environment (2010), and move all servers/workstations into the domain. In other words, completely changed scope and turned what marketing people thought would be a 30 second change into a multi-year project. But it needed to be done and after presenting our findings we were able to get management to agree.

That’s where MS Project comes in and you start tasking out everything that needs to be done: ensure no duplicate names exist, come up with new AD design, new Exchange design, migration plan, concurrent running plan, etc. etc. Or “scope-creep” as we like to say 🙂

I couldn’t have run this project without knowing the SDLC and how to manage a project. I later learned that my process of Project Management was actually called Waterfall these days and it’s what most people are doing.

I guess the point of this article is to introduce you to SDLC/Waterfall and Project Management and that I think Sys Admins need to wear the many hats. Sure you can go on forever without knowing how to run a project, but if you expect to move up the tree of life and get promoted and expect to run things, you should probably know how to do things that are not traditionally part of your job. Another great example of this is scripting. You can say you’re not a programmer, but if you don’t know how to script or write Powershell, you’re probably hurting your career.

Next week, I’ll start talking about Agile and its use in Project Management. I’m not a fan, so it won’t be pretty.