Project Salvaging is Microsprinting


Situation is simple, you’re someone who has been brought into a project at its last witching hour, there are not a lot of project management fundamentals in the room and everyone is constantly emphasizing the “we have to get this done, no time” analogies and metaphors at you. What do you do? How do you navigate this and salvage what’s left of the project to turn this around into a productive and usable solution.

Answer is Microsprinting.

The past 6 months now, I’ve been constantly brought into projects that have gone off the rails for one reason or another and it typically comes back to scope creep and lack of discipline in terms of leadership or more to the point communication.

This is why SCRUM is a concept that every developer should borrow ideas at the very least from, it’s not so much a rule book but a communication protocol that all can agree to and figure out ways not to bump into one another.

That being said, setting up sprints that go for week(s) are great but when you’re faced with a deadline that is measured in hours whilst having to also work back from an unmovable deadline you simply need to calibrate your effort to a micro format.

The List.

The way forward is this. You first analyze all the features that were expected to be in the release for the project, don’t worry about who did what wrong or where it went pair shape. Sit down, take a deep breath and focus on getting a list together that outlines all the features needed to be done. Take this list and break it down to a point where it’s not to finite but at the same time granular enough that all can accurately see what the effort ahead looks like.

The wireframes aren’t the spec.

A lot of times I see wireframes and folks are looking at these and going “Ok, I need that wireframe to be designed” which is a perfectly valid request, in reality though as an interactive designer your job is to not just paint pixels here but also decide on how the moving parts become interactive. More to the point, you’re also analyzing each of the boxes that say “news” and thinking about how the data template will look per item in the ListBox and so on, you really need to map this out per screen and come up with a fairly comprehensive list of both the interactive specification as well as a list of visual states that need to be designed end to end.

I say this as a box on a wireframe can turn quite dramatically into 2-6hrs worth a work depending on which direction the interactive designer decides – “Ok this box when clicked now will go to this screen and the transition needs to be fade along with a loading of individual boxes to lead the user as to what’s change in an elegant fashion etc”

Break the wireframes into detail as again the project is off the rails you don’t have time to sit back and create high fidelity prototypes for each wireframe around its interactivity. You simply need to outline what’s likely to be the effort and do the best you can to not screw up given the constant variables of time/budget is much shorter than you’d ideally like to work towards.

8 is the number, not 7 or 6 or 2…

Break your day into 8hr segments and these are effectively the Microsprints. Every 8hrs regroup and triage what needs to be done and what has been done, agree and move onto the next microsprint. It’s also important that you work with a stack ranked list, keep it simple, rank it from 1 to whatever and attack the list one by one until you get to the finish.

Chances are you may have 100 items but in reality given the timeframes are short whilst the budgets are tight; you’re effectively likely to end up with 70 items done at the end of the deadline.

It’s time to start sacrificing and yeah it sucks but if the project had of been mapped out properly from the start you’d have the full 100. The reality is its off the rails, you got to start triaging in a cold but fair way sort through the items that are going to have a chance of life and simply send flowers/apologies to those who want the items that aren’t likely to have a chance at life in this project.

Tough decisions but necessary ones.

Stakeholders are likely to be suffering from denial. “I wanted that box. Can’t we just..” the moment I hear “can’t we just..” is the part where I stop and think to myself “ok, is this a new idea or is this simply a creative way of trying to get agreement on something that just can’t be done”.

It’s now a point in time where you have 6 things on the table and you can only have 3. Choose as if you fail to make these tough decisions now, you will end up having less – it’s a reality and fact.

Don’t shoot the project manager.

At some point the project is off the rails, someone steps up and says “ok, I’m now leading this band of misfits”. It’s important that someone lead, but it’s also equally important that all understand that this is probably one of the worst positions to be in now. Projects off the rails remember, someone just stood up and said “I’ll now assume responsibility for this delivery from here on out” – give them the benefit of the doubt as they just did something you weren’t willing to do yourself.

They may say no more than yes, they may ask you to sacrifice your core beliefs on how things should be done in order for a Band-Aid or two. It sucks, but deadline is looming and having a 115 lines of code to do something that can be done in two may piss you off, but ship it. Ship it is the goal, refactor later.

Learn from your mistake.

Typically after I leave everyone has that exhausted look on their face, chances are some of the folks in the team will vow never to work with one another again. Emotions were high, we got it done, it wasn’t great but we got success.

Put your pettiness aside, understand this, it was a group failure that later turned into a group success. You just accomplished something that not a lot of teams can do, you made the deadline.

The thing is also, that whilst you know there is around 30 items off the list, and chances are the end users have no clue as to what those 30 items were. You’re just beating yourself up over a quality issue vs. an actual specific requirement.

Should that requirement manifest into a missing feature, you have the next round now ahead of you only this time, PLAN it.

Get the interactive designer into the planning meetings early; don’t leave the design to last. The interactive designer is responsible for the look, feel and way this user interface is going to interact. The UI designer is the person who will paint the pixels per state and lastly your user experience / usability rock star is the one who will navigate the cognitive science associated to the UI.

If you find a person who can do all three, lock them in and don’t let them leave. If you can’t find a person to do any of the above, start hitting Amazon and start researching as one of you needs to assume that position and take responsibility early for it.

Developers need leadership, someone needs to be the Program Manager, make them accountable for features getting to developers hands early. Project / Release managers are there to co-ordinate what should come first and lastly when.

You can have SCRUM approach, but democracies are only as good as its people. If the people aren’t clued into its virtues, see the above.

Learn from what you did wrong, don’t nail people to the cross for it..just learn from it.

Embrace MVVM.

If you’re doing Silverlight/WPF no excuses use it now. Don’t screw around, get onto it now. A friend said to me yesterday “..Dude, saying MVVM is half the understanding, once they’ve said it then they now know it..i mean Model..View…ViewModel whats the mystery?”

It’s a basic foundation for all to work towards and it’s just easy to set things in order in a solution.

Related Posts: