Wednesday, August 28, 2013

On Agile Project Management

I've often seen a bit of confusion around how to manage projects that are using Agile approaches for software development. On the one hand businesses are very receptive to continuous releases, however on the other hand they struggle with trying to fit the project budget and timeline into more traditional project management molds.

The trouble stems from Agile projects being measured on a velocity basis with the highest priority features being tackled first. From a project management perspective you have to keep an eye on what needs to be done, what has been done, how fast things are progressing, and that they are heading the right direction. Unfortunately the instruction given to them is to bolt this somehow into something like a PRINCE2 where the two are pretty distinctly incompatible.

How I visualize managing Agile projects:

You have a large furnace. This furnace burns money (logs) and produces business value. (steam) Developers, testers, and business analysts take the form of valves for directing the steam to practical goals. Your projects are funded by budgets which form different stacks of logs. Adding up all of the valves tells you how fast the furnace burns logs, that is a constant unless you add valves or increase their size.

Now as a project manager you have control over what logs get put in the furnace and where the steam is directed. The furnace burns a constant rate based on the attached valves. Something is always fed into the furnace, so you nominate the pile of logs to pull from, but if you don't specify, the furnace loader will just start throwing in anything flammable which could include the furniture.

A common problem that I'm faced with is when a project manager is trying to directly tie the output of one or more valves to the burning of a specific log. Between sprints, or sometimes even within a sprint they are tempted to fiddle with the valves to switch between different outputs while a log is burning. (This work needs to be billed against billing code X, while that work needs to be billed against Y.)

Some key problems with this:
Agile teams work most efficiently when they are not context switching between tasks. Each time you fiddle with a valve, steam is lost. Developers have to drop what they're doing, start something, put it down, and go back to what they were working on.
Logs burn more smoothly than shards. Project managers stop feeding logs, instead they try and budget for pieces of work and hand-feed just enough money from a particular pile to produce a specific amount of steam. Agile projects estimate on *difficulty* not cost. The measurement is how fast features are implemented, and when they're deemed good enough, not predicting how long something will take to complete. It might be tempting to pre-cut budgets to work in micro-iterations, however the reality is that staff and contractors are paid 9-5. You'll end up with 5 hours of "budget" spent to cover 8+ real hours of cost, and 3+ hours coming from "somewhere".

If you must context switch for budgeting purposes then the best approach I can recommend is to set it up as a completely separate furnace and dedicate valves to it. Avoid attempting to move valves back and forth frequently.

Does this mean that Agile teams cannot switch between priorities? Certainly not! They're ideally set up for dealing with shifting priorities, but what a project manager must tackle is how the logs are accounted for, and managing the valve changes as efficiently as possible.

1) Feed in the logs, and balance out the piles at the end of the sprint. At the beginning of a sprint set the valves. For these two weeks these developers will be working on these stories, while the rest of the team continues with Y. At the end of the sprint you look at what was delivered in both projects, account for which piles the logs for that sprint were coming from, and what the valve settings will need to be for the next sprint. This is a different frame of reference, at the beginning of the sprint you aren't allocating 3 logs from budget A, and 7 from budget B, you are merely setting the valves and putting 10 logs in the furnace. Based on what you get out at the end of the sprint will determine what piles the logs were pulled from.

2) Look at the quality and type of valves available. Some valves leak more than others, especially when fiddled with. Valves can represent individual members of the team, or groups within the team. Fewer large valves will direct the steam more efficiently than lots of small ones. Overall, the less you fiddle with valves, the more efficiently the steam is materialized into product. Getting into the habit of grouping developers into larger valves is also beneficial when you look to grow a team to increase the burn rate for the furnace. Adding 10 individual valves to 10 existing individual valves will mean you have 10 new, fairly leaky valves. However if you had developers grouped into teams, new developers can be merged into new teams with some or all of the developers from the existing teams to tackle new challenges, or added to existing teams. Developers reinforce each others efforts which helps mitigate leaks. (or at least brings issues to light early to be addressed.)

How does this fit with efforts to get budget approvals, set deliverable feature sets and delivery dates? I can't answer that, but I hope my perspective above gives some food for thought about how to better fit it into more traditional frames of reference, or convince upper echelons to to better fuel Agile projects and continue to see the benefits to the end deliverable.

Thursday, June 27, 2013

On Deadlines

It's been pretty busy with one of my current clients. The deadline looms for a release, issues are being uncovered, worked on, resolved... The development manager's facial expressions are changing faster than Melbourne's weather, and the project manager is scurrying around like a Corgi that found it's owner's Ecstasy stash. Just the other day the PM came up to me and asked "Steve, how can you be so calm?" Everything in the project is tracking well, the users were happy with the previews, it was just pre-release jitters. I didn't really have an answer for him, so it was just a bit of humorous banter to lighten the mood. It's not something I've really thought about much as it just seems natural by now, but after thinking about it I thought it might help others deal with stress, deadlines, and potential confrontations in the workplace.

My secret to staying calm is that I don't over-care. Over-caring is when you try to take the world onto your shoulders, give 110% and then some, do whatever it takes! Rather, I invest in the projects I work on. I allocate a reasonable amount of my energy into the project, and can choose to invest a bit extra to push through difficult spots. If I didn't believe in a project then I wouldn't be working on it. In the end, there is always the possibility that the project won't succeed, but if it fails, I can remain confident that it won't be due to something within my control. Also, by being conscious of what I invest in the project (and where) I don't have to get overly distracted by "taking ownership" for a project, which leads to conflicts, time wasting meetings, and frustration.

This is in-line with my general philosophy of life. I live by a policy of Truth, and with a focus of doing what I feel is the right thing, even if it isn't always the most popular thing. This allows one to be supported by their convictions. When you don't waste energy trying to mislead people or mislead yourself it is much easier to view things around you in a more objective fashion. You see opportunities you would otherwise miss if your thoughts are clouded by wondering where you'll get the extra energy to maintain any deception during an inevitable crisis.

Some key points people will notice while I work:
1. I am paid for what I do, not how long I sit at my workstation. Does sitting over your keyboard staring at misbehaving code help you figure out what's going wrong? I doubt it does. I'll browse for ideas, catch up on news, go to the bathroom, knock some balls around on the pool table, see if there's someone else's problem I can help out with around the office or on StackOverflow. When I worked for a company that wrote software to manage a postal print house I'd often spend a few minutes from time to time reloading printers and helping out with the manual mail inserting. It kept me in-touch with the guys that would be using my software plus frees up my thought processes. The context shift lets me spot a new idea when it sneaks up. In the end, all my client needs to decide is whether the amount of value I deliver to the project matches the fee I charge them.

2. I focus on memorizing as little as possible. Preconception is a productivity killer. Convincing yourself that you "know" things leads to arrogance and making assumptions that can easily waste your time plus lead to confrontation within a team. There are people that can just soak in information and retrieve it on demand, and provided that they do it accurately without falling into arrogance it can certainly be an asset. "Googling" or checking out something on StackOverflow should never be viewed as an admission that you're somehow a sub-par software developer. Knowing how to find useful information, absorb, and apply it is a very useful skill.

3. I judge things by what I see people do, not what they say. Before I engage anyone in a discussion about an approach I prepare or select examples outlining my thoughts. I expect the same before I'm convinced of an alternative. There is no build up or stand-off beforehand turning it into a big debate of principles or best practices, just show me code and I'll show you mine. Often by comparing two ideas we come up with a completely new approach that captures the best of both. Other times I'm convinced or doing the convincing and both of us come away knowing more than when we went in.

In general this avoids conflict and confrontation in the workplace, keeps my mind free to spot opportunities, and avoids stress build-up. When I maintain myself in a relatively relaxed state of mind it is very easy to switch into a high-gear to clearly see a problem for what it is and solve it. If I allowed myself to be burning high-octane by default there would be nothing left for the inevitable crisis, and running hot would most certainly lead to mistakes and fuel for those crisis'.

Finally some sci-fi quotes to live by: (What kind of programming geek would I be without them!)

"Understanding is a three edged sword: your side, their side, and the truth." - J. Michael Straczynski

"I've been around long enough to know how ignorant I am. I don't assume the universe obeys my preconceptions. Hah! But I know a frelling fact when it hits me in the face." - Christopher Wheeler (Spoken by Rygel from "I Shrink Therefore I Am")