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 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.
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.
Which are you? a developer or designer?How far we have come and yet how so little we have learnt! As someone who worked in/with the Silverlight/Expression teams to make sure the message that Microsoft has entered the UX space and that we’re essentially building a mutated Developer meets Designer and vice versa pixel ninja type person, the reality is people still need to put you into a category. I often find myself torn between which side of that fence line I sit. As to be blunt i can do both, I know every single API inside Silverlight/WPF like the back of my hand, I can code in 9 languages outside of .NET and aren’t script kiddy languages either. I can do 3D and 2D design to the point where many have commented on my abilities here as being “eye for design” or “you are freakish good” but still i’m tormented by having to pigeonhole myself either category. The reality is people aren’t ready to accept the person who can do both just yet and it takes a lot of proof to build trust that you can do both. I’ll let you know how I go with this journey over time but for now suffice to say, its new territory for me and yet still profitable as I can easily pick left or right and just swim in either pool where needed.
I need a UX guy urgently.I've seen this a lot in the past 8 months. I get called in at the last sprint or towards the end of a project and find myself having to triage features vs design vs engineering constraints. It’s the worst time to engage a UX/UI person(s) as in the end you’re asking for a Hail Marry - “can you make this UI look good and functional oh and don’t change the code base in the process?” is a common brief. The trick I’ve learnt is that I can do it, it just takes a lot more patience and focus –, and you really need to know every single backdoor into Blend as well as the Silverlight/WPF API’s. IT is a challenge but can be a success if there is enough time and the communication is clear and expectations are set properly. The bottom line is folks – Engage early and often. Even if its just 1 or 2hrs of their time per week or day, make sure you have someone in the room who bleeds UI/UX from the beginning of the project. Don’t engage late as the price will go up you won’t be able to salvage as much as you think by then it’s not a UX consultation its just a pixel polish.
I don’t use Blend, just Visual Studio.You are breaking my design heart when you say this to me. Everybody right now who reads this open up Blend and pick a fight with it. If you take the time to get to know it and get to know it well, then when used right can help you out enormously with both Silverlight and WPF development. If you’re a person who likes to indent and keep their XAML neat, stop right now, you are trying to skate up hill. XAML is not meant to be a hands-on language. It's a common data format created to allow Design and Code tools to work against the same model without giving up their inherent capabilities. If you are editing it by hand just stop as you are not doing it right.
Pick a color any color.The amount of times I've walked into an engagement and seen a rainbow of colors in the UI has left me thinking that it’s not so much a lack of will power around design it’s more the reality that not everyone is up to speed with color theory (there is a science to color selection). The easiest tip I give people is this. Typically a brand has one or two colors that are used the majority of the time, then they will use white or black for the majority of the content depending on the background composition (white for dark, and black for light). When you design a User Interface for your next Silverlight/WPF project, pick one or two colors and create a ResourceDictionary called [ThemeName]Colors. Then take that color and break into four shades (2x dark, darker and 2x light, lighter). Now then select what I call your chrome colors, these are the colors you would use for the outer chrome of your UI, in windows its typically around 4x shades of gray (light, lighter, dark, darker) and label them accordingly (i.e. chrmeAccent1, chrmeAccent2) etc. Keep your color naming conventions abstract (use camel or Pascal case – whatever lights your design candle). Now don’t use any more colors. Lock that in and use these. Don’t deviate at all from this plan unless you have a designer person in the room who is held responsible for retaining the product/projects brand. Lastly and this is the most important thing I can say to developers world wide:- Don’t use bold colors. Stick to pastel or light colors as you’re typically not ready for the hurdles that bold colors can throw at you. In saying this I did also notice that the MetroTheme that Microsoft has put into play has me a little nervous as it relies heavily on bold color scheming – which is great and cheap way of avoiding depth in a UI but at the same time creates a potential color scheming hazard around highlights vs lowlights and focal areas of your GUI composition. Typography is also another concern of mine as too much reliance of ye olde text can put UI two steps back instead of forward – people don’t like to read in general, visuals often handle the workload – review the many articles available on "extraneous cognitive load" for proof of this.
MVVM that is all.I get that some of you want to get gung-ho with PRISM, MEF or your own framework. Bottom line is this, if you’re starting out and haven’t figured out the tricks and hacks just yet of WPF/Silverlight then you are better off sticking to simple MVVM. It handles 90% of your workload and doesn't require you to learn WPF/Silverlight and an extra layer of complexity at the same time. Keep it simple, work to the idea that the code you write in the first year of WPF/Silverlight is code you will want to throw away or refactor later on. It’s natural you write bad code or work onto something that a year later you'll look back on and proudly say “What was i thinking”. You've got your Microsoft UX training wheels on, embrace this openly and you’ll do just fine. Walk into a room and pretend you have it all under control and you’ll fold eventually as you can’t credibly hold that facade for too much longer. If you can also check out AutoFac as well, this again will compliment your codebase nicely. MEF/PRISM are really for folks who have a team of engineers and are looking to build a complex mammoth size system – that’s the reality even if Microsoft try to deliver a different message – I'm an ex Microsoft Product Manager so I can spin with the best of them 🙂 hehe.
UI and UX are two different things.I need to say this out loud. If you ask someone to do UI, then they will do just that; focus on designing a user interface for an existing concept. If you need someone to wireframe and help you figure out how the whole user interface can be built, that’s where a UX person comes in. They are two different work streams just like a developer and a DBA are different. You can find people who do both, but keep that in mind.
Oh, I need someone local.Yes, having someone onsite is definitely a goal a team should always be on the hunt for. SCRUM teams etc benefit from this and it doesn’t need to be evangelized further. I will say however though, having someone working remotely can be just as effective especially a guy like me in Australia. I say this, as at the moment I’m working on a project with Microsoft and it’s working out in our favor as while they sleep I work, while they work I sleep and we’re able to have a show & tell (i.e. remote stand-up) with one another where the design and development work can meet in the middle actually pretty well. As I’m able to say “ok here’s what I’ve done for you, its in your inbox when you wake up” and in the afternoons they’re able to go “ok, here’s what I need for you to start my day tomorrow” and so the cycle is a 24hr development run that works quite well. It’s not for everyone but so far I've found it works without any issues other than an expensive mobile/cell bill from my end lol.
Show me some of your work?There’s a reason why painters and builders never work on their own house – same goes for me. This blog as weak as it looks is still the front door for my company – RIAGENIC. I need to get off my ass this month and put my site up but the problem I have is distilling what I do into a webpage that makes sense as I’m my worst client (picky, arrogant and will agonize over every pixel and paragraph in the site). I also need to find a way to promote me but at the same time associate myself with a brand, so that for me is a tricky marketing hurdle. I’ll soon see if I can pull it off! 🙂
Find people you can trust and don’t have to babysit.I’ve worked with a lot of developers in my time, nothing annoys me more than baby sitting incompetence. I’m fine with newbies learning the ropes, that I find far more rewarding as you’re working with someone who has passion and a determination to learn. It’s the people who are lazy and expect you to spoon feed them every 5mins on “how”. I didn’t learn Cinema4D by sitting next to a 3D wizard and ask “Ok so how do I write an xpresso script that makes the wheels rotate per frame”, I sat on Google and the objective was this “Find how to make wheels rotate in xpresso” and eventually I found it. Along the way I learnt a lot about Cinema4D and Xpresso as i was hunting for my answers. If you work with me, I will set the benchmark high per person I meet, I will quickly assess your skill set and then raise the bar to challenge you to meet it as I do want to work with people who get it and are smart at what they do. That being said, I love nothing more than coming into a cubicle of developers and feeling like I'm the newbie in the room as now I’m in learning from others mode. At the moment I’m working with Joseph Cooney (one of WPF’s first MVP and of learnwpf.com fame). I’m learning heaps from interacting with this guy, and its a fun project at the moment we are on. I don’t have to babysit him and he doesn’t have to babysit me. We just looked at the specifications, agreed on a solution structure and boom, were’ off grinding pixels and code. The next job I go to where they need a WPF/Silverlight dev etc, Joseph is one i’d recommend – again, its about networking and building relationships and finding people who you can trust and work alongside.
Reputation is a false economy.I often hear how folks worry over their reputation. I’ve watched people spend way to much time either building or recovering it from a bad project etc. The simple truth to this from what I’ve learnt is that if you know your work, you approach things with openly and honesty and don’t dump and run as well as admit mistakes, you’ll come out fine. Just focus on doing good work, reputation has a habit of following and self regulating itself over time. At times people I've heard bad things about on a project often aren’t the ones at fault as the recruiter / business development sales person didn’t set expectations appropriately or the project was a train wreck well before this person arrived and they were the last ones to hold the steering wheel as it went off the road.
Agile/SCRUM is not a religion.I’ve seen a lot of developers follow this concept by the book to the point where I often wonder if they are conscious of how badly they have gotten. The correct way and the natural way are two different things and in the end communication is the core piece to this. Stop arguing over protocol and just focus on establishing a clear line of communication and work on getting estimations as close as you can while at the same time admitting to your fellow team mates the moment you can’t do something or are over on your estimate – just put up your hand and say a simple word - “help”. I personally work under the assumption I'm the dumbest guy in the room, it keeps me calibrated and if you work with me and think “geez i thought that guy knew all of this” that's fine, but i probably do, but i’ll ask anyway just to make sure. I’ve felt the wrath of a false hero before, and I ended up having to do his work and mine at the same time only to be burnt for it later on. I could of thrown this person under a bus and said “well actually it was his fault” but in reality, I just absorbed the blame and avoided working with this person since. That is all.
Note: I am a UX/UI Ninja for hire.Contact me at scott at this domain.
I’ve not decided yes or no on that question, I’ve read a lot in the past few months on the topic and I’m still not convinced or swayed either way.
Here’s my open transparent written exploration of how I am navigating this concept.
UX Design vs UI Design.
Its important to split a hair on this one, UI Designer in my definition is someone who can work on the aesthetics of a component whilst a UX Designer is the one who contemplates how that component is to be used by humans (I could go much deeper in this topic but another blog post for another day?)
I state this concept out loud, as when I read success on how UX + Agile came together in XYZ team, I often question what they are measuring success in terms of UX and more to the point what disciplines were in the room and what were the problems being solved. I’ve not read a lot about how the sausage was made, its more “trust me, UX + Agile works” belief system which to me is simply not scientific enough to subscribe to. I need proof of life.
The UX Scouting Model.
There’s a number of articles written on this, but for me I call it the UX Scouting model, whereby you have a set of effort that works ahead of a sprint, its the type of work that solves the problems of UX before the engineers arrive at a point in time to start assembling.
On paper, this seems like a reasonable approach to the problem of dealing with iterative design, and I’m inclined to believe this is probably the only model I can think of that will yield a successful shipping cycle. Having said that, i think this kind of model is more suited towards a validation / mentoring of UX model than an UX problem solving exercise.
What do i mean?
I put it to all that what is occurring is a reactive iteration occurring on the software whereby you’re taking a slice of the feature catalogue and reacting to how it injects itself both technically and visually into place. This is where I think the failure points occur, as its where a seasoned UX Designer shows his/her skill set the most. The ability to foresee what’s next beyond the current iterations (ie sprint) and are also trying to forecast the next few moves ahead (heh maybe a good interview technique for a UX expert is to play chess with them).
Having this foresight is in my opinion a very rare amount of talent to have, and once that person(s) have this, getting them to also negotiate with both stakeholders and engineers on such direction could also reduce the skill pool down even further. It doesn’t stop there, as at times the engineering side of the fence line aren’t open to adjustments in thinking, as it means more time/cost to them and the project. It’s then you face the compromise concern, as once that card gets thrown into the room, its easy to bias the stakeholders or owners of the said software to side with an efficient release over an effective one.
It’s how a lot of software ends up with a degree of “false affordance” – meaning, you get packets of the software where it has a perceived level of functionality that does what it’s expected to do, but in the end it either goes un-used or un-noticed or even more so, it’s sole purpose is to placate the end user and stake holders into believing the problem was solved.
Let’s get it right next time?
Historically, Microsoft as a company has always duke it out over the battle between function vs form, and all to often function has won out in the end – despite the highly paid talent of UX leads being in the room. The stark reality is that time/cost are a factor one cannot simply deny, and its essentially what makes UX + Agile an attractive proposition, as it means get it done, get it done early and you can always get it right in the next release.
Microsoft typically takes three shipping cycles to get it right, when I say right, I mean “good enough” which in many ways is the ready, fire, aim approach. Apple at times seem to approach the equation from a ready, aim, fire model.
They don’t always get it right, but the amount of “luck” Apple have had with their product lines over the years, can lend itself to the concept that maybe they are siding with Form over Function every time. The company presents itself as being more about the industrial design of the solutions vs the good enough approach and it probably is why they often lead with a linear model of development + release.
Does UX + Agile work inside Apple? I don’t know, I can speculate that probably it doesn’t and that the engineering side of things makes way for UX – ie Function follows Form.
Back to the point, UX + Agile is sometimes hidden under the covers of evolution, whereby the said persons can run parallel or ahead of the said development teams and are able to react according to the growth of the said feature(s). However, when the time comes for a UX refactor, does it not get pushed aside into the next major release cycle with an open promise to get it right then.
If that does occur, then is that cycle dedicated to UX refactor in its purist sense? or is it just the same rinse/repeat formula whereby you have an iterative situation unfolding.
So, UX + Agile isn’t the answer?
I think the concept of Agile is fine, its the execution of it that I think is where the story kind of starts to fall a little to the way side, I think from a UX standpoint you really need to outline the features ahead but do so in a way that is suited to a ready, aim, fire model. It also needs to lend itself to a dedicated chunk of time purely to refactor the function of a solution to accommodate the consistency and goals of form. Having said that, that “Form” needs to be defined early and it needs to be framed in a way that everyone involved can subscribe to easily enough (heh, the joke is on the UX itself, as in order to sell everyone on the UX vision, they in turn need to ensure its palatable enough for them to recall, thus UX sells UX ..funny)
I’ve not decided as yet that UX + Agile is a formula that works, I can’t decide that just yet as I feel we in the software industry are back to pioneering mode. We settled on a rinse/repeat formula for so long that it started to breed mediocrity in the way software is designed, developed and deployed. Given the device market has created an interesting interruption in the way we approach mundane tasks, it in itself has elevated the B2C or B2B markets in a way that forces the ideation phase of software to take more risks.
The problem isn’t with the ideation being unwieldy or requiring strict time boxing, it’s simply we may have all forgotten to add the UX tax to the software builds – meaning, costs just increased.
Cost increases aren’t swallowed well, so the reality is what is likely occurring in UX + Agile teams is that there is more of a UI Designer validating and placating the said engineering side with “Good job, keep using DataGrids” mentality vs.. a UX Designer asking that folks think differently and outside the box.
On paper, agile is fine. In practice, well, grab your UX six shooter and lets ride off into the west and see what we find out next.