Agile Project Management

March 28, 2013 ← Back to home

Agile Project Management has been a buzzword for several years now. It is often used as something YOU must have to be successful. There are "consultants" charging over $10,000 for 2 days of training on the agile process, while you can get most of the "training" for free somewhere online. You will also hear about, Scrum, Kanban, XP (extreme programming), Velocity, Story Points, Poker Planning, Sprints, etc... All of those buzzwords and process concepts come down to some really simple things. I will do my best interpretation of the Scrum implementation of the Agile process, and then I will explain why people are spending way too much money on a process that they don't necessarily need.

I will try not to make it complicated.

Let's start with some definitions:

Backlog: a list of ALL Epics, Stories, and Tasks.
Epic: a large module of work explained
Story: a definition of work broken down from an epic
Tasks: a specific definition of work defined to complete a part of a story
Sprint: an iteration of product cycle. Often sprints are 1-3 weeks.
Sprint Planning: a meeting at the beginning of the sprint to plan what work is going to be done in that sprint cycle.
Stand-Up (often referred to as scrum, which is incorrect, Scrum is the name for the entire process): a daily 15 minute meeting where you state, what you did since the last stand-up, what you are working until the next stand-up, and if you are blocked (NOTHING ELSE), oh, and yeah, you are supposed to STAND UP for the entire meeting, there is a reason for that, it forces people to keep it short.
Sprint Retrospective: Sometimes called a post-mortem by people... a meeting at the END of the sprint where you ask: What went well, What could have gone better, and what actions are we doing for the next sprint to improve?
Poker Planning: People have cards (often based on Fibonacci numbers) to "size" stories. Sizing == Complexity. Sizing does NOT equal time (hard concept to grasp for project managers).
Kanban: literally means billboard in Japanese, but a spin of agile where you have a WIP (work-in-progress) and you continually work and take on new stories when you complete your story and move the story to the next workflow step (Backlog->Development->QA->Ready To Accept->Approved->Released) This topic could easily be a multi-post, but this is just an overview.

You have a backlog...

Release planning the project manager "grooms" the backlog to define stories with acceptance criteria and make sure the team understands the stories (poker planning occurs here, not ALL stories are sized, just the top ones (top is relative))
You have your sprint planning meeting... your team decides how many of the top stories we can take for the sprint... make sure you understand the stories.
You task out your story and start working...
You go to your daily stand-up and say you worked on stuff, you are working on more stuff, and you are (or are not) blocked.
You keep working...
Repeat steps 4 and 5 until sprint ends.
You have a sprint demo, where you demonstrate what you accomplished in that sprint (that means the stories should have something demonstrable).
You have a sprint retrospective and decide what you want to try next sprint to make the process better
Repeat 2-8 indefinitely. Step 1 is repeated at less frequent intervals.

Congratulations, please pay me $10,000 for that in-depth consulting about the scrum implementation of the agile process.

It is not more complicated than that. The problem comes when product management asks the age-old question: When are we going to be done? Done is a relative term. At the end of the sprint we should be "done" with what we agreed upon in the sprint planning meeting. What about ALL of the stories? Well, at the end of each sprint, you will determine how many stories points (sizing, Fibonacci, t-shirt sizing, etc...) you completed, then you see how many points are left to do... and that is your estimate.

IMPORTANT NOTE: The more sprints you have the more accurate your estimation will be. ONE SPRINT SHOULD NEVER DETERMINE YOUR VELOCITY.

There is a term call the Cone of Uncertainty If you ask me how long something will take, the closer I get to being completed, the more accurate my answer will be. That seems silly for me to explain but apparently, that is a concept people are not aware of.

Example: If I am running a marathon, at the beginning of the race someone asks, when will you be done? I'd say around 6 hours. (if you know me, it would be indefinite, because I would die around mile 8 :-) ). Then if someone asks me at mile 8, I should have 7 miles to determine what my average pace is, and I would be more accurate... if someone asks me at mile 26, knowing I have .2 miles to go, I would be almost exactly accurate. When I finish, I will be 100% accurate.

The concept is this... the closer I get to the finish, the more accurate I can be about how long it will take to reach it.

You often hear comments like: We have deadlines! We need to promise our customers these new features. OK, then after we release them, let them know about all of those new features. If we release every 2 weeks, you will have high contact with our customers letting them know how much we are improving every two weeks (or your sprint cycle). Don't finish a sprint, and say YAY UNTIL IT IS IN PRODUCTION BEING USED BY YOUR CLIENTS!

Now, that you understand how scrum works, here is my take on things.

Don't waste time doing stupid things
Check to see if you are doing stupid things
Refer back to #1

Is it more important to write code that works and is maintainable, or to write tasks to describe the work I am eventually going to do? Is it more valuable to have a day long meeting to discuss what work we are doing next, or simply start doing the work?

I have NEVER (yes, I said never) seen a software company be successful from planning work successfully.

There was a saying I heard a few times, "There are 3 frogs on a log, the third one decides to jump in the water, how many frogs are on the log?" "3, deciding to do something means nothing until you do it."

Stop wasting time discussing things, DO SOMETHING! Project Managers be available for development and qa questions. Don't send 20 emails to decide something, stand up, walk over and ask them. Hire builders/coders/doers, not talkers and analyzers. Most companies have enough planners.

Here is my simple guide on improving morale, moving forward, and creating a successful product.

Plan SMALL - One really small feature that is complete is better than 100 that never see the light of day.
Implement immediately - Make it work!
Refactor immediately - OK, now make it work elegantly. with test and documentation.
Release immediately - Give your clients your best code as soon as you can.
Repeat 1-4. You will become a better developer, have a stronger product, and establish patterns that will help your product be amazing.

Simple, Elegant, Documented, Tested Code - A dream that needs to be a reality

Thanks for stopping by...