- Part 1 – Stressful
- Part 2 – Code Refactoring
- Part 3 – Branch Workflow
- Part 4 – POC, Strategy, and Design Challenges
- Part 5 – Acceptance Criteria & Punting
- Part 6 – Tools, Extra Merge Day, and Postponed Transitions
- Part 7 – Bugs, Unit Testing, and Throughput
- Part 8 – Demo, Burnout, and Feature Juggling
- Part 9 – Scope Creep
- Part 10 – Conclusions
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.
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 new, untested technology, across the board (PyAMF + Flex GUI + Django + HTML/JS/CSS + custom camera firmware + bunch of back-end and middle tier stuff I don’t understand)
- 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…).
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.
If you have a Flex project you need me to do, let me know.