In this article, I reflect on how my first time in Agile worked on my current project.

Last One to the Party

In talking with friends and colleagues, it was pretty apparent I am
the last one the party. Somehow, I’m either one of the last people in
the Flex/Flash world to have used Agile/Scrum on projects, OR they
aren’t using it correctly/consistently, yet telling me otherwise.

Assuming I am in fact just unlucky enough to not have worked with
Agile teams, the only thing I can then surmise is the following. In the
initial days, I worked with a lot of agencies, and thus Cowboy Coding
was the rule. By the time I started to get on larger software projects
with more established software companies, I was in a consulting role.
Thus, I’d be put into situations specifically for clients that DID NOT
use Agile practices, hence the need for consultants. That’s the only
logic that makes sense. My guess is, if I were to go find a company
that produces software as a W2 employee, I’d potentially have a
high probability of using Agile vs. some made up process or Cowboy
Coding. Either that, or I’d demand they do, and get stuck being a
manager. Not that it would be a bad thing.

Design & Functionality Importance

I bring up this section because many have emailed me asking
specifically about balancing getting functionality done in an iteration,
and getting design changes/fixes into those iterations as well so the
designer(s) can see how the design is working. Since RIA’s make a big
point of incorporating a lot of custom design elements, this effort,
while leveraging the platform, does take time; time in addition to all
the regular software developer duties.

One thing that Scrum made pretty clear is what the client views as
important. Scrum is a development process that involves the client.
Throughout the years, the #1 reason teams that build RIA’s have
friction is no clear edict of what is more important. The leadership
and/or management does not dictate what is more important: design or
functionality. Everyone just assumes it’s design AND functionality, and
they are left to their own devices & political clout to get their
area of responsibility completed.

Developers already have a lot of things to do with not enough time to
do them. When you add design to the mix, you are adding more work, yet
not adding additional time. Do I make this dynamic list component draw
without ravaging your CPU, or do I fix the menu bar to look like the
design comps? They collectively will take more time than the developer
has allotted. Therefore, they’ll end up doing whatever they think the
client wants more; aka, what they’ll either get yelled at about less, or
what the client will gloss over, perhaps not even mention. For a lot
of developers, this is design.

While our client certainly put more importance than most on the
design because we’re building a consumer, public facing product, they
still wanted it to “work first, look hot second”. Naturally, they
didn’t say that; they wanted both at the same time. Yet, I only got
yelled at for non-working things; I was merely chastised every so often
for the design not looking correct. Both implied I needed to get those
tasks done. Using the law of Utiltarianism,
I’d often put priority on functionality since the client wanted those
done. That, or I just would get more negative reinforcement for broken
things, and less for non-nice looking things.

In the Scrum context, this means more user stories and defects were
created towards functionality than design defects. Additionally, they
were higher priority. Notice how I said design defects; ALL components
that did not have the original design comp look and feel were defects.
That means it was a failure on my part to not implement as designed,
and thus did not pass acceptance criteria in our bi-weekly UAT. Since a
lot of our components were custom and had challenging functionality, I
had no choice but to focus on the functionality first, and design
implementation second. Sadly, this happened on just about every
component I did because I often did not allocate enough time to sit down
with the designer ahead of time to ensure it looked correct. I did in
the beginning of the project, but as we started finding our design
needed some tweaking, I ended up spending more time re-factoring and
re-writing code vs. making it look good; since we still didn’t know if
would work right.

The downside to this is that you start to endanger the design if you
don’t get it finished early enough. Design changes can be more costly
than data model changes. When you’re data model changes, it usually
affects everything in your app; your ValueObjects, your Model, your
Controller code, and your Views. Sometimes this is minor, but the point
is, it touches EVERYTHING. While a design change may just affect the
View portion of your app, a lot of time, you can’t refactor to the
design change because it’s so sweeping. Thus, you actually do yourself a
disservice if you put it off.

The only thing I know to do to lessen this challenge is to ensure the
UX and/or Visual Designer create designs that are more easily
implementable; whether that means skinning in the Flex SDK, or Flash CS3
Components. That, or you’ve clearly thought out how much work is
involved in creating a custom component that looks like it does in the
design comp. Guessing tweak time is impossible, so you just have to
hope your code is flexible enough if the designer/client decides to
tweak it vs. scrap it.

While more innovative designs may make a major impact in both sales,
marketing, and case study opportunities, it effectively jeopardizes your
development schedule. Design wisely.

Leadership & Management

One of the things I learned in my 2nd run at college was how
leadership makes or breaks companies and projects. I feel like we had
great leadership on this project, and great management on the Scrum
process. Compared to my past experiences, and thinking what it’d be
like without those resources, I can see how it would of risked this
project from ever getting to alpha. No need for a lengthy section here:
While Scrum has proven to be great for this particular project, nothing
beats a great project manager experienced in Scrum with client buy-in.

Project Appropriateness

This leads me to being curious about my next project (yes, I’m now
looking for my next gig… had too much fun to look during like you’re
supposed to). Specifically, if Scrum is appropriate, and if not, what
do I do.

Startups = Yes

For example, Scrum for this particular gig felt like it fit like a glove for the following reasons:

working with a startup who wasn’t entirely sure what they needed;
wanted to ensure they could explore, yet still have working software
during the process in order to demo to investors if need be

working with a startup on tight budgets; needed the ability to
project how much functionality would cost, and when certain
functionality would be done in order to coordinate multiple efforts

So, I feel confident in working with startups in the future.

Design Agencies = No

In all the agency work I’ve done, you either A) never know
requirements until it’s too late or B) think you know, and things go
horribly, horribly wrong. Your designers are too busy to give you
clarity, or they are awaiting clarity themselves. In that case, they
aren’t forthcoming with information because they’ve already re-done
their comps twice, given up on wireframes, and are seriously frustrated.
You’re asked time estimations not for planning purposes, but merely as
a formality to ensure sales hasn’t pissed you off enough to purchase a
gun. I could go on and on…

Cowboy Coding, FTW.

Small Components = No, but would like to

Some of the smaller contract jobs I get in between the big ones are
building small Flash or Flex components/widgets. They usually involve
some agency or firm who already knows what they want, they just don’t
have the in-house talent to build it so they outsource to me. The
budgets are usually always pre-set, and deadlines aren’t as negotiable.
That said, most already have wireframes and design comps, perhaps even a
Flash prototype or two already built. I almost never use a framework
(Cairngorm, PureMVC, Mate, etc) on these projects, although, some can
last 3 months (complicated video players for example).

I don’t think Scrum could work with these types of projects. First,
the client is usually at least 2 degrees away from me, and the
relationship has already been created. Second, the client usually has
their own process, which is slightly different since I’m an outsourced
contractor (or remote team member for team augmentation). Therefore, I
adopt theirs. Third, it’s a lot of times a component in a larger
project, which already has it’s own team, process, and client
relationship. Fourth, the deadline being “set” goes contrary to the
point of using Sprint User Story completion metrics for Backlog
completion projections (i.e. the team typically completes a certain
amount of work each week, so since we have “y” amount of work, we’ll
complete it in “average time per set of work” * y = total time to
complete).

That said, it certainly would be a lot easier when there is a fixed
budget, and the amount of work is still in question. Even when the
deadline comes, there would be no surprise of where we’re at. A lot of
times, those deadlines are so intense, it’s challenging to even get a
build ready to show because by the time you do, the time is up.

How Much Does It Cost? = No, but could be Yes

I’ve worked with companies in the past where my efforts and those of
my team directly dictated price quoted to client. I’d give time
estimations with options, and those would be presented to the client.
There were 2 problems with this. First, the time estimations, like all
things done without using real Sprint metrics, are just guesses at
worst, inferences at best. Both are not accurate. Second, they implied
a false cost. Although I was never punished for going over/under
pitched cost during actual development, I’d often get nervous project
managers when I ran into “problems”. Showing them builds never seemed
to help ease their pain since to them, they just wanted it “done” since
they didn’t want to explain to a client why they were being shown a
“half-done” project.

If they were sold upfront a variable cost project, with fixed costs
used as a guide to show them how much it’d “probably” cost to build, and
involved in weekly builds, it seemed Scrum would of worked really well
there. In fact, I’d argue because of how fast we were at doing the same
type of software over and over, they’d be inclined to spend more.

Building Software Products = Yes

There were a few companies I worked for in the past
that definitely could of used a Scrum process. The first failed to
benefit from early builds. This would of saved us in being able to demo
a working build earlier to the stakeholders and potential customers.

The second company I worked for developed multiple products. In
retrospect, one of their products WAS using a semi-Scrum process, while
mine was not. I reckon the reason was mine was perceived as smaller in
scope, and thus not worthy of spending the time building a Backlog of
user stories since the very process of figuring out what we were doing
was extremely exploratory.

A third company had a 6 month project that had a huge Backlog, but we
only chewed a tincy bit… because no one knew we had a Backlog. Had we
all involved management & stakeholders into identifying what they
really wanted, and started showing them valid progress of what we could
do, it would of made it easier for them to predict time frames vs.
guessing. Another challenge was that things were changing rapidly. Our
project, in an Enterprise setting, took a 90 degree turn 4 months in.
A lot of the code was still valid, but it wouldn’t have been
a noticeable shock (vs. the near de-railing that occurred) if it were
merely more user stories that suddenly had priority on the following
Sprint.

Finally, for the B2B consulting I’ve done, I’d definitely see it
working great because the client relationships in those cases was
already pretty intimate. It’d be wonderful to have planned UAT sessions
vs. the makeshift builds and iterations we tried to do (and did do…
sometimes…).

Final Conclusions

I’m glad I finally got to be a part of an Agile Scrum process done
right. I finally see how software can be done right: People who care
with a good process. In retrospect of my writing above, I can also see
why my smaller Flash projects never got much better even as the
technology improved. They just weren’t a good fit for a Scrum process
because they were either so small in scope, the scope was unknown, or
the process was already locked into place before I got involved. I can
also see why I’ve gravitated towards Flex. It wasn’t just because the
technology was better for building larger Flash projects. It is because
I tend to get on more larger scoped software projects that often have a
more established project management processes, and thus help ensure
success. In my recent case, using Scrum.

In short, it’s nice to know if done right, I can focus on the
important problems; like figuring out how to build software components
in code instead of worrying about if the project itself will careen off
course and die.