Agile Chronicles #4: P to the Oh to the Sea, Strategy, and Design Challenges

The Agile Chronicles is a set of articles documenting my experiences using an Agile process (Scrum) in software development on my current Flex project.

1. Part 1 – Stressful
2. Part 2 – Code Refactoring
3. Part 3 – Branch Workflow
4. Part 4 – POC, Strategy, and Design Challenges
5. Part 5 – Acceptance Criteria & Punting
6. Part 6 – Tools, Extra Merge Day, and Postponed Transitions
7. Part 7 – Bugs, Unit Testing, and Throughput
8. Part 8 – Demo, Burnout, and Feature Juggling
9. Part 9 – Scope Creep
10. Part 10 – Conclusions

This entry is about creating proof of concepts that tackle challenging components in your application before Sprint #1 starts, when Strategy happens in the process, and the design challenges that still exist.

Proof of Concept

The POC stands for Proof of Concept. It’s a formal term used to describe the process in which a programmer tackles some of the high risk functionality items of a finished design comp to assess their feasability before the official start of the project.

At least, that’s what we define it as. The concept of iterations in software is to flush out the real problems with a design. When you have a 2 week deadline to code something, reality comes around really quick to expose miscommunications, not well thought out designs, and generally a firm challenging of assumptions.

…and there is Flash. With the amount of creativity expressed over the years in both design, multimedia, and applications, the reputation has grown that Flash Player is a wonderful platform to build your dream; an application rich in good design and experience. Like Apple products, only on the web.

This naturally makes things significantly more challenging for the programmer. Yes, the Flash Player, and subsequent software libraries (Flex SDK, Papervision3D, fluint, etc.) do help, but bottom line is, some of the components these designers create for us to build are just insane. Flash has allowed a lot of their ideas to come to fruition, so they are conditioned to do what a lot of good designers do, and raise the bar. There is a fine line between insanity and genius, and designers know it. Whether they are smart or not, they know that if a programmer can pull off some of their crazy ideas… it’ll be an extremely cool app.

Therefore, when looking at potential design comps for an application, you can pretty easily point out the things that look impossible to pull off. Rather than start going down a path you know will end in failure, you can chose to bring it up, OR prove it can’t be done in a reasonable time frame. Again, anything can be done, it’s the time element that is always the first metric for success. The POC relaxes that constraint a little bit, and lets you tackle the big items; the crux functionalities of how the app will work. You know these things will come up without even doing an interation, and since they are so insanely hard, you don’t even know if you can pull them off, you allot time to try.

For example, the ones I did were:

1. Can you scrub a Flash H264 video frame by frame instead of using keyframes?
2. Can you show hundreds of images instantaneously in Flash?
3. Can you cache bitmaps utilizing Flash’s local SharedObjects (Flash Cookies)?
4. Can you draw thousands of data points?

Now, keep in mind, this doesn’t categorically “prove” you can pull the functionality off. Remember, a Sprint is supposed to produce a real feature in real software. Test code you wrote working vs. the same code implemented in a real app are two different things. What it DOES do is at least ensure your Sprint has a modicum chance of success. Or, it could be a core feature to your application as a whole; even more important. For example, while I successfully completed all 4 POC’s above in a reasonable time frame, #3 did NOT work in production. Saving local SharedObject’s in Flash over 10 megs really bogs down the SWF. I didn’t think I’d have scaling problems; I mean, why would I? The Settings dialogue allows you to set it to “unlimited”… *face palm*. While I’m sure I could work on optimizations, that was not time I allotted for the original task, thus jeopardizing getting the user story it was associated with in the Sprint.

Again, iterations really do help in nailing down what can / can’t be done in a reasonable time frame. A few well chosen POC’s really help challenge assumptions about complicated components on a design, ensure you have a fighting chance doing them during a Sprint, and serve as a good litmus test for the team. If you don’t complete it, is it your lack of ability or the technology’s? In other words, the litmus test is somewhat subjective, but your team’s reaction to it is real and actionable.

Strategy

A project manager had written me an email asking “When does strategy happen?”. To answer, before I come in. Meaning, this project’s design and business strategy/planning was all completed before I came on board to really contribute anything of value. The POC’s were utilized to challenge key functionality, but beyond that, all wireframes, comps, and plans of for product launch and components were all ready to go. May someday I’ll care enough to plan, but for now, that stuff is boring to me; I like building other people’s visions.

Design Challenges

One thing using Agile/Scrum processes hasn’t solved is the same design issues I’ve always had. Those are:

• The designer has to see a working version of their designed components before they can truly define how it’s supposed to work.
• Design comps do not express how something works.
• Flash / AfterEffects animations do help express how something works, but get out of date quickly.
• Fonts are a PIA.

For some complicated components, the team really didn’t know some of the finer details of how it should work. So, I’d have to guess, make a quick build, upload to the server, and show the link to the designer. I’d then call him on the phone and work through it. It was actually a pretty quick process, but made me feel insecure sometimes because a lot of my point estimations (and thus time estimations) weren’t really aimed at figuring these things out. Yes, I’d designate something as hard if it looked hard to pull off, but I had already assumed I had a decent understanding of how it worked… which was wrong for a few components. This happens to me in every project.

It’s not so much the components, but rather, how they interact with other components. Once you start wiring things together, you start to see the application in a new light, and holes in the user interface are exposed. A lot of times they are minor, but those minor issues add up in un-accounted time. I don’t know how to fix this. Unless designers can physically sculpt the application with instant feedback, I fail to see how they can effectively communicate to me how it should work. So while I respect this, it’s really challenging to plan time for it. It’s also frustrating because you have to just make a gut decision and pray it’s close to what the designer wants. Then again, it’s better to be doing this in quick Sprints with only a few user stories working towards a valid build vs. an entire app over the course of a few months.

Wireframes and design comps are great. I couldn’t live without them in the more complicated projects. The more detailed, the better. The downsides to them are they get out of date quickly, versioning is a bitch because UX and designers don’t use version control, and all the CMS systems like BaseCamp don’t make it easy to keep track what version you are looking at during meetings where all of you “open the PDF” only to find you all have different PDF’s. Additionally, as an engineer, I make extreme inferences on how things work. The designer then goes through it explaining it, and this usually changes a lot of my inferences. While good, I’m still making inferences. An inference is an educated guess. That’s another way of saying, “I think I’m smart, so ensure I don’t look like a moron to my readers, I’ll use the word inference instead of assume to avoid all the cliches”. While perception may be better, it’s still an assumption.

If a designer takes the time to knock out a quick Flash demo that’s clickable or even just an animation showing how the app works, this is extremely helpful to those are visual learners. I’m audio, so just need to talk over the phone; others need pictures. Regardless, it’s a lot more iron clad than a comp. The downside is, it’s more work for the designer and they can get out of date when you decide you no longer like the functionality in the end of week UAT. I’d rather have and use them vs. not, though, that’s for sure.

Finally, fonts are still the biggest pain the ass in Flex; same as Flash, only different IDE. Sometimes they work, sometimes they only work for one developer, sometimes only on one OS. You then start doing lines of coke whilst trying crazy ideas such as renaming the TTF file names, finagling with your CSS, and generally trying all kinds of shotgun approaches to “get it to work”… that don’t.

Conclusions

I’m glad I had the POC’s to do in the beginning. They really did help give me a broader picture of what the stakeholders felt was challenging, what I perceived as challenging, and what everyone perceived as important. Besides, it’s nice to get the hard stuff out of the way first so you can focus on being awesome. While a lot of great online services have come about to help the development process, design to me is still touchy feely throughout the entire life-cycle, every Sprint.