Agile Chronicles #10: Conclusions

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

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 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…).

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.

If you have a Flex project you need me to do, let me know.

8 Replies to “Agile Chronicles #10: Conclusions”

  1. Thanks Jesse for a series of posts fit for the annals of time! i had the good fortune to work in the agile process for a few months and long to get back to it. mostly cuz it does soooo much to support project management (which supports us) and distributes the responsibility to team members beyond engineering. thanks again.

  2. Hi Jesse,
    I enjoyed reading your experiences on using Scrum. I discovered it on my latest project too, and I also really like it. Up till now I had only seen projects with death by paperwork or cowboy coding, so it was nice to see a process that works for small teams. I’ll definitely be looking at using it again

  3. Whenever I hear a developer say that designers should “create designs that are more easily implementable” I can’t help but laugh. Clearly the developer is missing the point of software. There is no software on the planet that is intended to make the lives of its own developers easier. However, virtually every piece of software (that has a GUI) is intended to make the lives of its USERS easier.

    Just to be clear, UX/Visual/Interaction Designers do not just design stuff for the sake of looking nice. We design interfaces for the sake of making the software meet the needs of its users in the most appropriate way. Because most products try to solve different problems, there is no pre-built set of components that can be used to accomplish that. As a result, we do design things that may be more of a challenge to implement.

    As for the question of what’s more important. I have seen the same types of reactions as you during the development of a product. From sprint to sprint the stakeholders want to see that functionality is working correctly. Often times, the trade-off is made and design is sacrificed to the Scrum gods. However, without exception, when the product is released and people, even internal people, start using it, they all start to complain about how difficult those pieces of functionality are to use.

    Clients need to understand that value of a better user experience. That is not always communicated correctly. For example, when an application is intended to be used by call center associates, knowing that a particular custom component or interaction pattern can reduce the time to complete a task by 20% (which is a realistic number for a well designed task), the value of the “design” might make it a higher priority.

    Showing a design element to a client without the reasoning behind it would be like asking the client if implementing a Hibernate second level cache is a higher priority than finding the help button on the screen. Without explaining the value of a second level cache, how can they accurately make a determination of the priority.

    In short, sacrificing a better user experience so that some piece of functionality can be built in a 2 week sprint is certainly not the answer.

  4. Great points Rob; I was getting a little worried with all the positive comments on my series of articles.

    That said, I think there are a few important things to point out that I might not have made clear.

    The first is, again, making designs that are hard to code has a business impact. I don’t mean to sacrifice the design’s ability to provide an easier to use product, I’m talking about simpler things such as only making 8 states for Buttons vs. making up your own. The Flex SDK Button has 8 states; most only use 4 (up, over, down, disabled). Designers who don’t create those states, or create their own make the developer’s life a lot harder, and in turn this takes up valuable time that could of been easily remedied if the designer just knew a little about the Flex SDK and what native skinning features it supports.

    Now, when the need arises to create a Button that differs from the Flex implementation because valid user testing data shows that it’s a valid decision to do so, I’m all for it. However, history has shown me more of the former, the designer making things harder than they have to, is more prevalent than the designer making things harder for the sake of user ease of use.

    The easier it is for me to execute, the more assurance you have that functionality will actually work. If functionality actually works, that means more time to play with the design based on user testing data. If it IS hard, then I’ll end up spending a lot more time on getting basic functionality to work, let alone getting the design implemented. There are a ton of compromises that can be made that won’t adversely affect the user’s ability to accomplish tasks in the application (assuming you’ve validated those decisions with actual users). My point is, from my experience in both Flash & Flex, I haven’t seen those discussions happen in a positive light; a lot of times there isn’t a lot of dialogue, or the design isn’t perceived as “fluid” by the team.

    Secondly, those 2 points above; does this make it harder, isn’t really discussed nor validated. You bring up selling UX whereas most times during my project it all comes down to user stories with time estimations. I still think it’s valid in Scrum and doesn’t negatively affect design; I did in fact factor in my time estimations the design parts of the components. What I didn’t do effectively was involve the designer enough in my work-in-progress builds. That wasn’t a failing of the process, nor was it a failing of the team to sell the client on UX; it was my fault for not prioritizing correctly, pure and simple. The client already has a great appreciation for good design, and recognizes it’s impact. My execution just needed a little better prioritization, and I feel I’ll do tons better next time (just like every project, hehe).

    Also, I TOTALLY recognize the law that users should be first. I married a Usability Engineer. If she were commenting, she’d basically say you and I are both full of shit until we test the design first. Only once users actually use the build in progress do we get validation on what parts of the design and functionality are actually “working” with factual user testing data.

    Unfortunately, we did user testing during our first alpha. I was vehemently against this, and since Day 1, I tried and failed multiple times to sell a good user testing strategy. My wife already works for a company, AT&T, that has user testing built into their process. While that’s nice, it proved too challenging for me to create a user testing plan and incorporating into our process amidst doing development.

    Also, please keep in mind I abuse the word design a lot. When I say, “Getting the design in”, I’m talking about getting the skins, the colors, and the shapes correct. I may have gotten the tiled list with drag and drop features like the iPhone finished like the designer wanted enough to show the client, but not the correct colors, fonts, spacing, text formatting, and rounded corners. That DOES have an impact, and I recognize that.

    However, if I spend 0 time on design, and 100% of it just getting a simple draggable tile-list working, and make very little progress in 3 days, it’s pretty clear we won’t be able to make it work like the designer wants. While we may even have user data to supplement the positive explanations form the designer, the mere fact remains that the execution is beyond the teams abilities. It doesn’t matter if it’s the right thing to do, it’ll never get done. Other times, it may only take 3 additional days, but the team fails to sell the client on how 3 days, with 16 man hours will equate to a positive user experience once completed. While it may have been right, the ability to communicate that correct decision was at fault, not the team’s ability to execute. That, or the client being a startup on a limited budget cannot afford the better design because it takes longer to implement. What do you do then? Compromise.

    Regardless, thanks for bringing up those points. Just because we feel like I’ve finally found a process for ensuring our projects go more smoothly doesn’t mean we should lose sight of what we’re really trying to accomplish, and those goals should come first, not following the process.

  5. Nice article Jesse. I agree with you that you are most likely going to sacrifice the design. It is really pointless on sacrificing the functionality. The other problem I came across working with UE and designers is they often don’t cover all the use cases and sometimes simply don’t like how things look.
    They also often change the design and functionality. Using scrum helps a lot. You know straight away that they are not happy and some adjustments need to take place. What is often forgotten is the fact that EVERY functional or design change will require more time. Things just don’t happen, they take time. Now this extra time that is required is usually never in the original project estimate and falls onto the developer. At this stage is down to developer what happens next. Working with other developers around me I’ve noticed that some people will simply compromise on design, some will work late and some will stand up and say: Hey, I need more time. There is too many factors (people you are working with, you freelance/are permanent, PMs, client, budget) to simply say what works best. Agile makes it easier. It make the entire delivery process more transparent and it makes collaboration much easier. I am a big fan of agile and I highly recommend it.

  6. Design Agencies = No

    This is so so depressing. In the past three years I’ve got convinced in the very same thing. It just doesn’t work with design agencies. Right now, I’m rethinking my companies process and how I can optimize it for working with design agencies. One of the big difficulties is how to persuade them to use a more effective communication channel – to be specific I really prefer wiki instead of emails with attachments and an endless search for differences.

    Have you ever used wiki (or systems similar to 37 signals basecamp) when working with design agencies?

  7. Nope. Wiki’s require work, and agencies don’t dig anything related to a process. In fact, wiki’s are hard to keep up during regular software projects as well. I’ve heard they work wonders for a lot of people, but not me.

    Cowboy Coding, FTW!

Comments are closed.