This article will discuss what Technical Debt is from a Flash/Flex developer perspective, how it negatively affects my Scrum projects, and what are some of the prescribed ways to prevent it.  Nothing ground breaking here folks, just corroboration that TD IS a major problem, and not even Scrum is immune.

What is Technical Debt?

Martin Fowler has a good summary about what Technical Debt is.  Here are 2 quotes from his wiki:

You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy – you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.

Git-r-done vs. doing it right.

Another quote which describes the metaphor:

…doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

He goes on to mention that unlike money, you cannot effectively measure technical debt. Additionally, you only get a return on your loan once you deliver.

Signs of Technical Debt

There are various signs of Technical Debt.  System fragility, tons of reoccurring bugs, or code that “sometimes” works.

System fragility examples include when you move a login button, the entire login form doesn’t work.  Another sign is when you change a ValueObject’s property name slightly, yet get no new compiler errors.  Yet another, usually a violation of DRY, is when you change a parsing error of a server’s response, yet still get the bug after compilation.

Another example is the statement “the application doesn’t seem to be working”.  If there had been diagnostic tools in place such as unit tests, a debug/log window, or other testing tools, that question could be quickly answered.  Even if it can’t, if you can’t quickly isolate problems after asking some follow up questions, that’s another indicator.

Another is when you fix a bug. 3 times. Over 3 Sprints.  Then it comes back in some other unrelated area.  Another is before the user even does anything you’re presented with one or more error dialogues.

The best are when you see the right data.  Sometimes.  You have no idea if it’s your fault, the server’s fault, or… what.

Bottom line the code has growing pains, and is challenging to change.  When you change one thing it breaks something else unrelated, your change is a pain to implement, or your new code duplicates a lot of functionality because you can’t borrow other functionality because it isn’t encapsulated enough to share.

The one that took me a LONG time to get over when I first started dealing with extremely large code bases was “fatique”. I’d get tired of dealing with all the problems, and feeling like I wasn’t making any progress. That, and I had no confidence in my changes because I wasn’t sure what the ramifications were, what would break, etc.  Effectively, I didn’t want to work on the project anymore. This has happened twice to me.  It’s not from my attention span, but rather just pure loathing at not being able to move forward.  Part of this is remedied in experience, part in “learning the story” of code base by spending a lot of time with it, and just general growth as a programmer. If you’re grown, and still have this fatigue, that’s another clue.

All these and more are signs of Technical Debt.  If not dealt with, they only get worse and more numerous.

Technical Debt’s Effects on Scrum

In Scrum, your user stories need to pass User Acceptance Testing (UAT).  At the end of every Sprint, your client validates each user story your team completed is in fact done.  If you have technical debt, this’ll eat away at the quality and/or dependability of your user stories actually working.  This means one or more stories won’t pass UAT.  This then slows down your, or your team’s, velocity.

This often will negatively affect your client’s view of the team as your earlier velocity will have been higher.  Usually your team will start off slow or fast, but eventually 4 Sprints in, a common velocity will emerge.  With a lot of Technical Debt, the reverse will happen; your initial speed will slowly decrease as your team struggles to cope with the increasing Technical Debt.  If not tackled, more debt is created, and your velocity stays slow, or decreases.

Technical Debt will also often exhibit itself as “bugs”.  In Scrum “there are no bugs”.  Benevolent Scrum Masters will assign 1 point to bugs.  This is often done to put a sense of accomplishment that the bug was completed, but more importantly that it’s trackable.  Its low point value can unfortunately skew to its business value.  Perhaps the bug is what prevented your original user story worth the maximum of 5 points from passing UAT.  Worse, if your team is working on fixing bugs, they aren’t working on user stories.

Again, negatively affecting your velocity.

Eventually your team will either have to pull back and pay off their technical debt, continually pay off a little to show some payoff, or just pray the client focuses on more pressing user stories in other areas and “forgets” the glaring issues.  I’ve seen all 3 happen.

Pullback & Reassess

Scrum doesn’t really have methodology for pulling back and fixing core architectural problems.  It’s generally assumed that 80% of your 2 week Sprint is spent refactoring.  I’ll let that sink in.

Done?  Worse, Technical Debt, being unmeasurable, wreaks havoc on a Product Manager’s ability to give transparency into the project for stakeholders.  You don’t often have a stable velocity; some Sprints your team could simply deliver 0 story points.  This makes it challenging for the PM to project when the Backlog will be completed and when certain milestones will be reached.  It’s even worse when managing budgets and getting contracts signed.  Scrum is hard enough to sell to clients who are used to fixed bid; suddenly Scrum sounds like a bait and switch, or just a money pit.  Assuming your team is actually working on the user stories they were assigned and aren’t trying to sabotage the project, then that situation is usually irrefutable proof that your team has some serious Technical Debt.

Software done with Scrum is like a plane flying from A to B.  While the flight path is continually corrected, eventually it’ll get there.  Planes usually can’t fly with ice on the wings, hence why you setup good architectural bases in the first 2 Sprints.  Ice on the wings during flight can be disastrous.

For some projects, sometimes you have no choice.  Your team has to take the hit, pay off the debt, and rebuild trust with your client.  Yes, these can be bloody, but hey… anything is better than Waterfall which in my experience ends like Lock, Stock, and Two Smoking Barrells: Tons of death, theft, and people get bling who don’t deserve it.  While this is effective with Capitalism, life is too short to product shitty software.

American Credit

While not an American only phenomenon, it’s certainly indicative to our culture, hence why Fight Club had such an interesting ending.  If you’re quick, good, and lucky you can get away with paying as much Technical Debt as you can per Sprint while knocking out a few new user stories as well.  Sometimes this is just how things are; other times, you’re merely postponing the inevitable day of reckoning.  Consultants are famous for this.  They get away with masking the massive Technical Debt, and moving on letting some other poor W2 (employee) sap, or consultants like me, to actually fix the Technical Debt.

Eventually, you have to fix the broken windows… or maybe “you” don’t, but someone does.  It’s easier to do this sooner than later.  I’ve even seen a team where one guy would fix windows 90% of the Sprint, and another would unintentionally break them again.

Pray for Priority Shift

The third one I’ve seen happen in larger companies who don’t adhere 100% to Scrum.  The priorities change for the user stories, and other parts of the application which are basically broken are ignored, buried, and eventually assumed to work.  Flowers don’t grow as well over a dead robot’s grave.

Incidentally, when higher ups find out, this is where I get some of my work.

Preventing & Fixing Technical Debt

As you can see, Technical Debt has devastating effects on Scrum, and Iterative Software in general.  The best way to ensure Technical Debt doesn’t negatively affect your project is to prevent it.  It’s like insect infestations in your house; if you don’t attack the problem early, it can be very challenging to remove.  The best way is to prevent the infestation in the first place by not leaving out food, water, and generally ensuring you have sealed entryways and windows.  Same with software.  Start with a tight, simple architecture, and continue to maintain it.

That sounds great from a high-level perspective, but what does that really mean?

Here’s a few I know & have experience with:

• good design
• good developers
• fixing broken windows ASAP
• OOP, specifically encapsulation
• unit tests with a decent coverage
• an agreed upon framework
• throwing optimization out the window
• using old technology
• Continuous Integration: frequent checkins & religious tagging

Here’s a few I know of, but don’t have a lot, or any, experience with:

• Test Driven Development
• Automated Build Systems
• Automated Testing (Hudson, Cruise Control, etc)
• Functional/Automation Testing (QuickTest and others)

Let’s go over these in short detail.

Good Design

The #1 thing that saves you the most time, reduces the most risk, and directly contributes to the efficiency of your team is a good deign.  Wireframes you hate since you’ve re-worked them so many times with gallons of dead tree’s at your feet, and design comps you love.  5 minutes of a designer’s time can save a week of a developer’s.  When you hit a brick wall during Sprint 5, a designer can quickly put your team back on track quicker and more accurately than a developer can.

Hire, and keep around, a good User Experience/Interaction Designer/Information Architect/Designer today!  If you’re made of epic win, hire a Usability Engineer as well.  They are the ONLY ones who can provide real facts to your team.

Good Developers

A common complaint of Scrum is that it only works with senior to mid-level developers.  I agree.  While it takes a village to build great software, you need to ensure your development team is top notch, or mostly top notch with a rockstar to guide the rest.  I realize this isn’t a reality for a lot of people.  Even if you have a senior dev, the bad developers can actually detract from the senior’s ability to deliver as he/she struggles to re-factor their code while ignoring their own user stories.  That or the bad/mediocre developer continually creates Technical Debt.  While developers not focusing on their user stories is a management problem, not a Scrum specific one, if they can’t even be professional and do what they are told, they are effectively sabotaging the project, and thus need to be removed.

Remember, small agile teams are more effective than larger ones.  If it ends up only being 2 heavy hitters, so be it.  Or you can just hire my team.

Fixing Broken Windows

Not much to add here other than they are usually one of the few things that can clearly indicate Technical Debt.  If you have to prioritize, choose to ignore the ones you can easily predict and reproduce.  They are less dangerous and take a lot less time to annoy your clients.  It’s when you go, “Whoa… never seen that happen before” is when you worry your client and PM.

OOP Encapsulation

One of the good concepts of Object Oriented Programming is Encapsulation.  It may seem silly to bring up something so basic, but it’s a basic, core concept for a reason.  Without good encapsulation, your code cannot grow, nor be flexible; something that’s VERY integral in Iterative development.

It’s ok if your API is good and the code underneath it sucks.  This is where Test Driven Development can shine.  Instead of “creating a component” from the inside out you actually write like you’re going to use the component yourself.  A better API usually results.  Then, you can focus on writing the guts to make that API happen… or not (see throwing optimization out the window).  It’s easier to fix bad code inside encapsulated, and thus easily isolatable components than it is sphaghetti code.  Sphaghetti monsters are waaaayyyyy more scary to fix than WW2 tanks that just need a new engine.

Unit Tests with Decent Coverage

Even if you don’t practice TDD, it’s still a good practice to implement unit tests on problem areas of the code.  TDD purists will state you should write tests first.  If you don’t, there is still a ton of value in writing unit tests, or getting good “coverage” of problematic areas.  Key areas include your Service layer or any code that accesses non AS3 data and injects it into the system.  This includes XML, text, JSON, AMF, binary data, and anything that “parses” something.

Strong-typing is awesome, but it assumes you started with strong-typing.  Parsing XML to ValueObjects is great, but if “That PersonVO is a Spy!”, good unit test coverage can usually point that stuff out early and save the team days of debugging and lost time.

Plus, it’s really awesome to blame with 100% confidence the back-end Java team for your woes in 7 seconds vs. 2 hours of frustrating searching for a needle in a haystack whilst being verbally bashed by the back-end devs wondering why you didn’t use HTML5 instead of Flex.  Suddenly Outlook does a cliche freeze before you can write a scathing, emotionally charged, career destroying email back at those over-architecting ($*&Us.

While they have less value on GUI components, some of the ways in which you architect Flex 4 components can actually facilitate easier testing.  Examples include really complicated components that NEED to be in a specific state when data is injected.  While a really complicated chart that has 100 unit tests around it still has to be visually verified, those 100 unit tests can help dramatically.

Finally, in those areas where you have good coverage, you can do minor refactoring with a ton more confidence.

Agreed Upon Framework

Doesn’t matter what framework your team chooses, as long as you all are in agreement.  This could even include using no framework.  I prefer Robotlegs, my partners prefer Swiz, and my clients often still use Cairngorm 2.x.  Regardless of your thoughts on frameworks, in my experience they help you manage, scale, and work with a team on larger code bases.

Premature Optimization

Knuth once said:

…premature optimization is the root of all evil.

After awhile, common optimizations you do by default, and to me, aren’t even considered intentional optimizations.  Some are small, low hanging fruit, that you can do without even thinking and make into habits.  Examples include setting an Array’s length to a local variable instead of inside of a loop, using Object Pooling, and using visible vs. removeChild.

Good programmers constantly want to make their code better.  Sometimes this means faster or more responsive.  The really good ones know when to leave a TODO, and move on.  Most users are happy with a reasonably responsive GUI.  A programmer’s expectations of “responsive” is often way higher than what a user will accept.

Code it and refactor later.  You can’t refactor vaporware.  Focus on pimp API’s.  Besides, this is ActionScript, not C.  We have certain limitations (no threads, a VM vs. all code being machine code, and a lot of missing optimizations).  Brandon Hall once said if you have a performance problem in Flash, you’re probably doing it wrong.  Instead of re-factoring code, step back and re-assess your approach.  Recognize those limitations early, and yell like crazy at the designer, “WE CAN’T GO TO THE MOON IN A TRICYCLE YOU FRAKIN CRAYON PUSHER!!!?”

If you have something to prove, do it at night and post to your blog.  If the GUI isn’t responsive, well duh, that’s not a bad optimization, that’s a required one.  The point here is if you need to prove through tests cases that by not doing your optimization(s) that the app will be unresponsive, you’re either in dangerous time sink territory, or doing something amazing.

Use Old Technology

While I love using Flex 4, a lot of the apps I still work on, and clients have in development and/or production are Flex 3.x.  Flex 3.5 & Flex Builder are solid, 4.0 SDK and IDE, not so much.  You want your problems to be programming challenges, not unexpected scrollRect or IDE magically disappearing code hinting bugs.  These things can be major time sinks and devastating to your productivity, sometimes killing your entire day as you attempt to reinstall & reconfigure various things.  Mitigate those risks by using old software that works and has a proven track record.  Most won’t listen to this paragraph and I don’t blame them.  Flex 4 skinning does help a lot in the “make this design work” department, although, no one talks about the overhead costs of putting an icon in a Spark button, and all the other simple things that are now more complicated.

Software traditionally outlives it’s original expected lifespan by 3 times or more.  One of the reasons is that it works.

Continuous Integration

Continuous Integration is a gigantic topic, and actually encapsulates a lot of other sub-topics I’ve already mentioned.  I just want to focus on the parts of it that I found extremely helpful and harmful if not followed.

The first is checking in your code often.  If you don’t know how to merge code, learn.  If you don’t know what tool to use, use BeyondCompare.  If you’re on a Mac like me, use CrossOver to make BC work (I’ve been using that setup for 4 years).

Even on a 2 man team, merging and testing your changes can take a lot of time, even if you and the other developer are on completely different sections of the code base.  On one project, we actually set a specific merge day on the 2nd week of our 2 week Sprint to ensure we planned for this disruptive day.  We’d both merge frequently, but we’d still ensure we didn’t merge much more after that since it can wreak havoc on UAT day.

Regardless of what source control system you use, you NEED to implement tagging.  This doesn’t need to be a team thing at all; just give 1 person responsibility with this important task.  Every UAT day, they need to tag the build.  Developers in general should make their own tags and branches, but sometimes the code isn’t in a risky spot and you don’t end up doing it.  That’s ok.  You should still have Sprint tagged builds so you have SOME saved point to confirm/deny major bugs/changes against.

Test Driven Development

I won’t go into detail here, but I’ve seen the positive benefits on my Service layer, or when I’m writing a library for others to use.  For both, you actually create the API first and it feels immediately relevant.  Additionally since the Service layer is often the weakest link in your application it’s great to proactively find bugs that would of usually cost a lot of time early on.  That, and you have a dependable suite to test for changes that may negatively affect things later on.  Finally, you can test if the entire applications communication system is working within seconds, quickly killing assumptions that add to debugging time.

What I haven’t resolved yet, and this is probably due to my inexperience with it, is how to manage the amount of code I have to refactor.  No longer just the components, but the tests often as well.  This is especially true with some of my more complicated GUI composition components where I test the controller layers.  Maybe it’s my inexperience with TDD & unit tests, maybe my tests just aren’t very good… I don’t know.  Like any problems with the GUI, I just blame the Designer.  That doesn’t make the re-factoring amount & time go away though.

Automated Build Systems

Automated build systems include things like ANT and Maven or even Rake.  This is the #1 question that sabotages my sales call when talking to Enterprise clients.  They want to here me say, “Why yes, of course I’m a major proponent of automated build systems.”

I don’t, though.  ActionScript & Flex Dev isn’t Java, and is a lot simpler.  I’ve seen more team productivity lost to setting up & maintaining build systems.

… except for deployment.  When you’re deploying to various servers, and doing integration testing with different systems, I’ve seen TONS of value here.  I’ve only seen this work if you have a dedicated build person who doesn’t mind having a lower story point contribution.

If I can’t hit the run and debug buttons in Flex/Flash Builder, I perceive that a serious problem.  I’ve seen many teams who can’t do this, and fire drills rage.  Once you solve that problem, you can start tackling other problems.  There are many who disagree with me, but they are nowhere to be found on my consulting gigs where I’m saving a project.

Automated Testing

The King James Bible says in the 10 Commandments that you shouldn’t covet your neighbor.  I’m an uber-sinner then because I’ve never worked on a team that had the chops, client permission, and/or resources to setting up and maintaining an automated testing server, yet I continually wish I had been, or soon will.  I’ve been on teams where we talked about it, but it was never executed because we too busy TRYING NOT TO DIE AND ACTUALLY SHIP SOFTWARE.

Hudson and Cruise Control look awesome.  That said, a lot of the people I’ve worked with don’t even write unit tests, so……..

Functional Testing Tools

As I stated, a lot of things in Flex are insanely visual; you can’t write unit tests to test visual accuracy.  That, and some of the state’s they get in are unwieldy to write tests around.  You can utilize functional testing tools to automate a lot of that… and man, seeing them in action is HOT!  They are wicked expensive as a result, and only the larger Enterprise companies employ them.  Here, too, is another thing that sabotages my sales calls with clients:

“You ever use Functional Testing tools?”

“No, but I’d love too, they look HOT!”

Conclusions

In my experience with Scrum, and Iterative Development in general, Technical Debt is the only thing I’ve seen that can really destroy the promises that Scrum is supposed to deliver on.  Thus, it’s been the one thing I’ve been focused on better understanding on how to identify, prevent, and fix.  If you’re using Scrum, beware.  Twice I’ve seen Technical Debt make a huge negative impact on my projects.

There are a bunch of things you can do.

Think heavily upon the decision of coding something quick vs. planned out well architecturally.  There are pro’s and con’s to each (OOP Purists will tell you nothing should be quick, they are wrong).  Sometimes you have zero clue if feature is even relevant to the your users, and it makes huge business sense to only make a quick foray vs. a huge, heavy architecture investment in case the user quickly scoffs at the functionality.  Patton called this a “calculated risk”.  Software IS War.  Other times, that quick implementation without any good architecture can have major negative consequences later down the line.  That’s ok, though, just get really good at refactoring.  Yes, it’s a skill you can learn.  Yes, refactor is a good word; it’s not the same thing as rewrite, and is integral to developing software well.

The other ones are ensuring you have a competent team, ensuring they follow commonly known practices, and tackle problems early.  Check your code in often and early.  If you don’t employ TDD, at least think about getting some unit test coverage on areas that continually are causing problems.

Remember, part of this recession was caused by people having massive debt they didn’t deal with, and ignored.  Debt is a valid way of doing business, and so is software, but you need to see some eventual value on that investment, and not let your debt get out of control.

If you ignore everything I said above, just remember 3 things: encapsulation, refactor, and use a damn good logger.

Caveats

I continually abuse 2 terms below, Backlog and Sprint.  Sprints don’t have to be 2 weeks, but for the sake of simplicity, I assume they are.  Also, Backlogs contain user stories, not requirements or features.  However, I assume for the sake of this article your features are already formed into user stories.  Finally, I assume that once I capture a requirement, it’s thrown into the Backlog.  I actually have a document which holds the validated requirements, which I then later formalize into user stories, and then put those officially into the real Backlog.  In this article’s case, that process is assumed to have already happened.

Review: What is a Backlog?

First, a review. A Backlog is a place you store features, or user stories. There are often 2 Backlogs for a software project, a Product Backlog and a Sprint Backlog. The Product Backlog contains all features for your software. At it’s purest form, it’s an spreadsheet that lists all the things your software is supposed to do, with a rated business value. While it can be seen somewhat as a requirements document, it is more defined, and singularly focused. It merely lists features/user stories.

While a requirements document may say “The application needs to allow users to register and login”, the Product Backlog would probably have that as 4 line items:

• Upon entering [product URL], and the user isn’t logged in, they’ll be presented with a login screen. They can enter their username and password, click the “Login” button. If the correct credentials are provided, the user is shown the landing page.
• If the user inputs the incorrect username and/or password, the Login screen is shown with the error message “Your username and/or password was incorrect”.
• If the user is already logged in when entering [product URL], they are automatically taken to the landing page.
• If the user does not have an account, and arrives at the login page, they can click the “Register” hyperlink to be taken to the New User Registration page.

There are a lot more user stories you can write, or even refining the ones above. There are a few points here in the difference. The client wants users to register and login. This requirement can easily be documented in a requirements document. That requirement belays a lot of work for developers, and a lot of things for the PM to track. Requirements are for capturing the client’s needs, but are not setup for clearly laying out what a developer should do, nor what the acceptance criteria is. The developers want clear instructions on what they are supposed to code with a clear acceptance criteria. Most importantly, the Project Manager needs to have trackable items, clearly documented, that are accepted by the client. Additionally, she needs to have weights and priorities attached to these items so she can track over time and give the client transparency into the project.

These units of work, called user stories, are stored in the Backlog. They are mutually agreed upon by the client, developer(s), and the PM.

Review: Sprint Backlog

A Sprint Backlog is where you put features/user stories that team needs to complete each Sprint. You put user stories into the Sprint Backlog from the Product Backlog. Once the Sprint starts, the Sprint Backlog becomes frozen. While you can add & modify things in the Product Backlog while the Sprint goes on, you cannot add/modify things in the Sprint Backlog. Additionally, the Developers are the only ones who actually mess with the Sprint Backlog. They’ll assign user stories to themselves, complete it, and move to the next.

What Are We Building?

One of the reasons for the high rate of software project failures is due to the software not being what the client wanted. Software is usually built to a specification or “spec”; a document that outlines what the customer/client wants. Clients are busy. Thus, back in the Waterfall days, you’d get a sales and/or PM to document as much of the client’s requirements as possible, formalize it into a contract, usually a Statement of Work or similar, and have both parties sign it. This contract was supposed to be what you were building, by when.

There were 3 huge problems with that. First, it assumes you accurately captured requirements. This is a fallacy. Communication is a flawed process based on the filters we humans use to understand other humans (my mind filters the thought into speech I believe you need to here, you hear this speech and interpret the meaning of my words, and filter it to what you think I said). Thus, you need to, rightfully, assume any documentation, even mutually agreed upon, is flawed.

Second, developing software is slow compared to making dinner. The business and/or customers who needed the software can change.  Software needs to embrace change to be relevant.  Iterative development embraces that concept whereas Waterfall does not.  Waterfall assumes you got it right “months ago”, and there is no room for the client to change their mind.

Third, it’s a myth that people can tell you what you want.  Clients think they know, even if they are actually involved in making software, but they don’t.  Usability testing is the only proven way in software to validate if your software works or not.  To do usability testing, you need to have a working build of software.  To have a working build of software, developers have to make a build vs. work on the build.

Iterative development forces you to make working builds every 2 weeks, and gives the client the opportunity to validate that your implementation of user stories are actually valid.  This also allows them to validate the software is solving their current needs, and if not, they can shuffle the Product Backlog around, and re-prioritize for the next Sprint.

The Product Backlog contains all of the features your software has, and the Sprint Backlog has the frozen features your team is implementing this Sprint.  The key here is that the Product Backlog can change.  Whether your client wants to re-prioritize, or they have new things they want to add.

Scope Creep

Scope Creep is defined as the scope, or total requirements for a project, growing over time.  The word “creep” is used to imply that it’s growing beyond the originally agreed upon scope, and it’s doing it slowly enough not to raise the ire of anyone beyond those actually designing & developing the project.  It’s the bane of web & application developers everywhere.

Unless you use a Backlog in Scrum.

If the client wants to add new functionality, they can.  Adding new functionality to a project is often a good thing.  Whether a good idea that could of only arisen AFTER a build of the software was used by the client, or a glaring hole in available functionality was noticed weeks later.  Sometimes the new functionality is just a piece of functionality re-stated, but with additional work behind it.  Developers usually hate this because while the client perceives it as “the same scope, just re-worded”, developers know that it’s 3 times the work.  First, they already built it; second, they have to re-work their existing work assuming it can be re-factored at all; and third, they still have to code all the NEW functionality added…

…within the same timeline.

Unless you use a Backlog in Scrum.

Remember, the Sprint Backlog, the things developers are working on during a given Sprint, is frozen once your team starts.  It CANNOT be changed once you start.  The client is welcome to modify, change, and re-prioritize the Product Backlog whenever they want.  If the functionality your team delivers at the end of every Sprint meets UAT (User Acceptance Testing… also known as “we built exactly what you asked”), and the client wants to change it, it’s added as a new feature to the Product Backlog.  This is huge.

This means that anytime the client “adds” or “changes” something, it’s clearly documented in the Product Backlog.  The key here is if your team already delivered a user story from the Sprint Backlog, and the client wants to change things, they can’t magically undo the completed user story your team completed.  It stays completed, and a new one is created for insertion into the Product Backlog.  This is a track record for the PM and your team to clearly show they client they ARE adding scope the project.  Your team IS delivering on what they were asked to do.

I don’t want to get into teaching the client, managing their expectations, etc. I just want to point out here that’s how it’s supposed to work, and that’s fine.  Most Product Backlogs grow as the project moves forward.  This is a good thing.  It shows things are evolving and getting refined.  Your client is getting what they want.  Your team is shielded from scope creep sabotaging your work and the client’s expectations.

Product Development Helper

I’m involved in 2 products currently.  One is an Enterprise Dashboard Framework for my company, and one is an image app I’m working on with Joel Hooks.  Both projects were well under way when I was brought on board.  Both project owners specifically asked me to join to help them accomplish 2 things.

First, they wanted to launch.  Second, they wanted an opportunity to do Scrum development.

While I have gleefully accepted helping them reach these goals, this put me in a few challenging situations.

Economics of Design Phase

From my experience in software, I’ve found (and read online to corroborate) that the most impact with least cost is spent in the Design Phase.  This is when the User Experience (UX)/Interaction Designer (ID)/Information Architect (IA)/Designer people/person figures out what we’re building.  To give you context, let’s pretend I charge $50/hr (<– lol!) and conveinantely leave out the design part (where wire frames are made to look hot via Photoshop/Illustrator/your mom):

• 2 hours spent on wire framing a Login = $100
• 16 hours spent coding the Login to work = $800

Now, the ratio varies, but typically development time greatly exceeds time spent wire framing.  There is also a dependent relationship here that the above math doesn’t show. Attention to detail & well thought out user stories implemented in the wireframes often significantly reduces the amount of time developers have to spend.

• 2 hours spent refining registration = $100
• 6 hours saved by devs not having to stop, lose momentum, ask questions, get clarity, re-work, wtf = $300

Another advantage is “cheap flexibility”.  If you want change your mind about something in Design Phase, it’s really cheap.  I’ll often utilize a pen and paper for creating software, whether that’s in the beginning, or after we hit a design/functionality challenge in the design comps and we have to go back to the drawing board as it were.  Drawing boxes and arrows, and then summarily ripping out the piece of paper for 2 hours until we get it right.  This, as opposed to having developers figure out mid-sprint, costing them valuable momentum, and setting them up to fail.  …and costing a lot more money.

• 4 hours playing around with the Landing Page = $200
• 2 days using developers to play around with the Landing Page = $800

Keep mind, your Designer doesn’t contribute, nor is beholden to, Story Points.  If you utilize your Developers to experiment, you’ve detracted from their ability to deliver on their committed stories.  This costs you twice: Their lost productivity they’ll have to make up, and by spending more money using developers vs. designers to play around with a design.

False Starts

I’ve tried & failed enough times at launching my own product ideas that I’ve learned what not to do.  The #1 problem I ran into was lack of design direction.  As a single man team, I had to do design, front end & back-end development, and product management.  That’s hard.  If you know the idea, the market, and are passionate about it, you can actually do pretty well simultaneously performing all of those roles.

However, as a coder, I naturally spend way less time on design.  That was consistently a mistake I paid for. It absolutely annihilated my momentum.  More importantly, as I got frustrated I didn’t have design direction, knowing I’d have to stop coding and do more upfront design work, I lost the will to continue.

Once you lose the will, you’re screwed.  You won’t launch.

Design Phase vs. We’re Almost Done

Thus, for both projects, I’ve spent a lot of time on the design phase.  This means everything from documenting what we’re doing, drawings and wireframes, and keeping track of our Backlog.

The problem is, both teams are rearing to go… they want user stories to munch on with Sprints.  The old adage here, “garbage in garbage out” still applies to the Backlog as well, thus I’m sticking to my guns.  While we collectively could extract what user stories there are, and sort by priority, without a good design to guide those user stories, we’re just going down a misguided path with awesome equipment.

I haven’t figured out how to manage this.  My only saving grace is that I can easily remember back to when I was “just starting” or “re-starting for the 4th time” that my will was waaaayyyy harder to break in the beginning; it was only once I had been working for 3 days straight, and hit a design brick wall that it crumbled.  However, if I was just thinking and playing around, my will could stay strong for months.

We Need To Do This Also: Work Intimidation

Both projects have their challenges.  For the Dashboard, I know the audience, so it’s pretty easy to wireframe for it, and outsource the design.  For the image app, I have no clue who they are, and the descriptions I get from her majesty and Joel, I can’t relate to.  So, I had to create Persona’s, validate these persona’s, and then create goals from them.  Even simple goals lead to a lot of software work.

Another problem I found with trying to launch a lot of my own products and failing was breadth of work.  Not scope, but the amount of goals the software was trying the accomplish.  I’ve found the amount goals you’re trying to solve is directly proportional to the amount of work you have to do.  I was only successful when I targeted a reasonable amount of goals to the created a somewhat reasonable amount of work.

At first, you think “man… that’s ALL the software does?  This’ll be easy… and disappointing.  There’s not much of a challenge, and I’m not sure my users will like software that doesn’t do a lot.”

Bullshit.  If you believe that, you’ve never launched software.  I believed that, then I failed 50 billion times trying, and eventually gave in, and tried to launch even something mediocre.

The incorrect perception I had to overcome was that launching, with all the hard work it takes, is the end all, be all.  It’s not.  A “launch” just has to be a working product normal people can pay to use.  Like any web based, or self-updating desktop software, you can iterate well after version 1.

I’ve constantly had to remind myself of this as I document & wireframe functionality for both applications.  I get really disheartened when I recognize a Persona goal isn’t met, implement it on paper or the wireframes, and recognize the breadth of work I’m creating for my team.  The fun challenge I’ve found is figuring out how much I can take away, yet still launch.  The key point here is “take away” merely means tossed in the Backlog.  Good, valid idea, documented, but not making the 1.0 launch cut.

I don’t have to feel bad at all, in fact, I should feel good twice over.  First, because I’ve significantly reduced scope, and thus increased our chances of successfully launching; and second, I’ve done my part and documented the valid feature, and stored it in it’s appropriate place.

Painful process, but I seem to be getting better at it.  I can’t imagine building the Google.com homepage.

Projects Backlog

I do a lot. I’m busy.  I work a lot.  Thus, prioritizing my time in helping with these projects actually creates a “Project Backlog” in my real life… one that I am not following very well.  I can only do so much in a day, and if I don’t prioritize my tasks into a linear list, nothing will get done.  So far, I’ve tried 3 day sprints where I focus on 1 project for 3 days, and then hop back to the other.

Some days, that doesn’t work, and I get confused on which one was I was working on.  At the very least, I at least try to do my “5 minutes a day” rule: spend at least 5 minutes a day working on the task.

While the ivory tower solution is to focus on 1 project first, and get it done, it doesn’t work like that because there are dependencies.  So, I’ve tried to balance it out by working on 1 project while the other is in a lull/waiting on someone else.  Sadly, it seems a Project Backlog doesn’t really work because I can’t freeze it like a Sprint Backlog, and there are too many dependencies out of my control.  I refuse to waste time, thus, I’ll just hop to some other project to keep productive.

Conculsions

If I had the choice, I’d probably just focus on project at a time.  However, this is way different than coding.  With coding, assuming I have a ton of user stories and design comps waiting for me, the onus is on me, and the time is full.  With designing & managing… sometimes I physically can’t do anything other than wait.  Also, some of the tasks I need to do are a lot shorter.  Writing a document takes 30 minutes vs. 4 hours to code a component.  Therefore, it’s way easier to shuffle a schedule around, and make it full of multiple projects vs. just 1.  While hard, I feel like I’m on the right track… I just need another 10 years of practice.

Bottom line, I’ve found the Backlog really helpful in both capturing all we want to do, and all that we don’t have time to do.  It shields my from my clients inadvertently sabotaging my team’s development on their project, while ensuring we capture what they need.  It ensures everyone knows what they need to do, are setup to succeed, and is trackable.  It kills scope creep dead, and helps me reduce software complexity.

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.

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 discuss how Scrum for the most part brings Scope Creep under control, the areas where it doesn’t, and what you can do about it.

Introduction

One of the most interesting things about Scrum that took me 4 months to realize is that Scope Creep hasn’t been a major issue. It’s not totally 100% under control mind you, but I’m really impressed that it hasn’t come up in any defensive discussions like it usually does, aka, “It’s not my fault we’re not done, I’ve been working insane hours, blame it on scope creep”.

Scope creep refers to the ever increasing requirements of your software as a project progresses beyond what was initially agreed. Scope Creep, to me, is one of the main reasons why Waterfall, while still a valid way to make money, tends to produce non-useful software. The view of most developers is that scope creep is bad because it’s new work that has to be done in the same time frame, a time frame that’s probably already aggressive.

The term is used a lot more in agency work because developers are more aggressive about ensuring they know the scope of what they are developing. Since the time frames are a lot shorter, there is little to no room for screw ups and/or re-factoring. Any misinterpretation of what the client wants and how it is supposed to work can be disastrous. The developer(s) may have to re-code a lot of things from scratch, work longer hours when she/he/they are already exhausted, and be extremely frustrated the entire time doing it. Naturally, this is the worst possible time to not only add additional work or modified work, but adding it without thinking about the consequences of doing so. This is usually a recipe for bad software not being ready on time, with the project manager(s) left in the position of explaining why things weren’t done on time, and the developer(s) completely at the end of their rope.

It’s not usually this bad… it’s always this bad. Scope creep sucks.

Being held accountable for additional work added after the fact is just cruel to designers and developers and a way to ensure things won’t get done, nor done even remotely correct.

Yet the sad truth is that scope creep probably doesn’t have malicious merits behind it. Business moves faster than software development. Rather, it is probably important (or perceived as such), a valid functionality addition/change, or a new business requirement because things have changed since the project/Sprint originally changed. The target demographic for the site may have changed, the users had issues with a portion of the design after simple user testing, or perhaps a business to business application needs to solve a new need since the rules of engagement have changed. While you may not WANT to change things, it could mean the difference between the software being useless vs. useful.  Most importantly, like all software, the more you use it, the more you start to learn what will make it better.  You don’t know this until features start working, hence getting new scope in the middle of a project.

The Backlog Holds Scope

Scrum defines the list of user stories (features you wish to your software to have) and defects (bugs) be documented in a “Backlog”. This is a list of 60 or more things that you need to get done. At the beginning of each Sprint, the project stakeholder(s) & project manager decide what user stories and/or defects from the Backlog will be attempted each Sprint. Each User Story will have an assigned point value (not the law, just some metric to identify the user story’s overall value & challenge to implement) while defects are worth 1 point. Based on the average user story points completed per sprint, you then add a few more to ensure developers are overloaded just a little as well as having tasks to fall back to in case a user story cannot be done or becomes invalid.

As you can see, Scope Creep is deflected (mostly) for 2 reasons. First, you do not alter the user stories & defects chosen for a sprint after the fact. If you do, this sabotages Scrum. You don’t know what your team can accomplish each sprint because you keep changing their tasks. You never know what they completed in a normal instance, and therefore, have no metrics to use for projecting when things will get done.

Second, the additional scope is probably valid, so any additional scope creep is documented instead, and put on ice in the backlog. Rad!

This has a few other benefits as well. The client, who is already involved in the Scrum process and thus has transparency into what is going on can clearly see their additional scope adding to the projected project release date. How? Do the math:

1. 3 developers are completing 25 user story points on average per sprint
2. The Backlog contains 125 user story points worth of work
3. If each Sprint is 2 weeks, the project will take around 5 sprints, and thus 10 weeks

The scope creep then adds 10 additional points worth of user stories.  That’s at least another week’s worth of work.

This is powerful because you can totally stand by your point of, “Yes, adding scope does in fact push the deadline.”  To this day, that “fact” falls on deaf ears.  $10 says if it were a hammer, it still wouldn’t work.  At least now you have factual data; best you can do.

Again, you don’t need to complete the entire backlog to finish the project.  A lot of times you get the backlog 90% complete, and the stakeholders go, “Ship it!  We’ll do it in version 2”.  The point here is that a nice place is created for scope creep, the backlog, and the user stories can be re-prioritized each sprint so they do in fact become priority when it’s appropriate.

Invalidating or Modifying Existing User Stories

This works for for new scope, but not modified scope.  Modified scope is functionality that’s either modifies what you are currently making, or invalidates it.  For instance, I was coding a scrubbable timeline graph in my current project.  We found that the level of fidelity we were drawing at made scrubbing an ineffective way of perusing the data because it wasn’t scrubbing at a high enough fidelity.  You can only move something 1 pixel by hand, although Flash can draw at the sub-pixel level.  We attempted to solve this by drawing the graph in 2 view’s with the 2nd view only showing 1/6th of the data, thus giving you a more zoomed in view.  This still didn’t work because it negatively affected the importance of another design.

After trying this a few times, our project stakeholder and the designer called it quits and decided on using a separate view we had as the primary way of finding what the user was looking for.  So, within 2 or 3 clicks, the user could find what they were looking for, knowing full well the capable fidelity of what they were currently using.

While effective, I coded the same stuff 3 different times 3 different ways.  Very frustrating at first but I was really glad to get closer because we have a design that works; meaning, it’s actually been coded and tested and does what it’s been designed to do.  If I look at the original design comps I was given 4 months ago, and compare to what we have now, it’s totally different.  This increase of scope in coding new views, and modifying old ones were based on good design decisions.  I made that sound like it went smoothly, but it didn’t always.  We all were very frustrated at times with our picture of how something should work not always bearing fruit of that vision in reality, ie, our bi-weekly UAT builds.

When I’d do daily builds to test things out, the temptation was to modify on the fly… and we did some of that.  That is why a lot of my original time estimations on my user stories for the sprint were grossly under-estimated.  Either the designer and I, or the client, designer and I would try different things each day or couple of days to see if they worked.  While good for the app, the 3 main challenges were ensuring our decisions were well thought out, ensuring our decisions weren’t reactionary to a build-in-progress, and ensuring the extra scope was documented.

This got really fuzzy.  Was it new scope?  A new user story?  A modified user story?  Additional acceptance criteria?  A defect?  I felt like a lot fell to refined acceptance criteria, which naturally pissed me off because it sabotaged my time estimations.  However, I’ve never been negatively held accountable for my time estimations, only my regressions (broken functionality that had been working in previous builds), so I got over it.

Another type of scope creep beyond the invalidation & modifications of the above was when something compelling arises during development.  Either the designer will take personal liberties that go beyond the initial requirements and create something that is just really frikin’ cool, or we’ll use a stable build, and think, “Wouldn’t it be cool if…”.  I will say the former has drastically changed the course of our project multiple times.  For example, our application is not about video streaming, but reviewing already recorded video.  Yet, when the designers created a Quicktime movie showing their vision of how it should visually work, the streaming really was a compelling part of the app.  Suddenly the CEO of our client, who had been pretty adamant about about not supporting streaming at all, was taken aback, as all of us were, about how cool it looked.

To this day, streaming is still a tincy business value of the application we’re building, but originally none of us perceived spending any time on it until the designer took us to the next level.  This was easy scope creep to manage because we’d just add a bunch of new tasks into the backlog, and modify existing ones that weren’t being worked on yet.

The worse ones, though, are the “Wouldn’t be cool if…”.  Those are REALLY hard to track, and really hard not to immediately implement.  At a bare minimum, I document most of those new tasks into VersionOne, our tracking tool.  Keyword is “most” here because some are so small you wouldn’t think they’d negatively affect your time tracking metrics, yet they do because they are so numerous.  This gets into the same theory people use a large upfront requirements gathering session during Waterfall in that they don’t want nit-picking on already gathered functionality.  If it’s not in the spec, you aren’t doing it.  Yet, perhaps there is a valid reason you should try to add functionality?  Then for Scrum, this should technically be in your Acceptance Criteria… yet it can’t be there either, because you didn’t know it’d be cool till you actually saw it in action, and had that “ah hah!” moment.  This would be the only area where I’ve seen scope creep negatively affect my time estimations, and strain my ability to be a developer vs. a client manager.  When this happens, I struggle between being a developer that loves pleasing the client creating cool new stuff, and a consultant who doesn’t like the client disrespecting the process that they signed up for since that’s a reflection on you also not running your process correctly.  It’s hard to balance, at least for someone who has a strong need for “approval” of those I work for.

Conclusions

Bottom line, I’m really impressed with Scrum’s innate handling of Scope Creep.  It clearly recognizes the importance of new scope that’s late the game, scope that may hold the key to making the software relevant or not when it’s actually shipped.  I think any new business requirement that drastically changes the needs your application needs to address won’t prevent your project from being sabotaged; business moves wicked fast compared to software development.  Regardless, at least now the #1 reason I’ve seen projects be crap when they are actually released as well as creating massive amount of loathing in developers towards the client & project managers they work for is brought under control.  For the rest that slips by, as long as you document it, it won’t sabotage your tracking metrics used for projections.

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 discuss how you fit (or don’t fit) a demo of your software into a Scrum process, the how burnout can skew your burn down, and the variety of ways of features can be cut, re-assigned, or re-designed.

Demo’s

I’m working with a startup out in Cali.  While it’s different for each startup, most get funding from some entity.  Those providing the funding will eventually want an update to how the startup is progressing.  I don’t know how these things usually progress, but based on my experienced combined with reading the startup blogs, it usually comes down to a demo.  Those in charge of the startup will report their status to the board/investors, and give a demo of the current state of the software.

If you read some of the failed startup blogs, it’s always interesting to find out the reason, but more often the reasons (plural) why they failed.  One in particular I read stuck with me.  It discussed how an all star team was put together, and how the CEO (the one writing the series of blog entries) discussed the different type of developers you could get.  The 3 classifications I’ll simplify here: git-r-done quickly, code her right, and experienced.  Apparently the CEO had experience with the git-r-done ones in the past.  They were great in that you could quickly get usable software, but once you had to actually sell it and support it, things went downhill since it was implied that writing things quickly resulted in hard to support software.  We all know that it’s never that simple, but he was simplifying for the sake of writing.

The second developer, and the one he had hired, was a code her right.  Meaning, the developer knew about writing scaleable & maintainable software.  The thinking goes that if you want to do it right, you spend the time up front to write it correctly, giving deep thought about your data model, your code architecture, and processes.  The writer points out that this actually contributed to their failure because they missed 1 conference and 1 investor meeting because the software was never demoable since it was being “coded correctly”.  In the end, the best written piece of software was never used by anyone.  Obviously this makes the Agile crowd neverous because you should be able to demo your software at the end of your first sprint (2 weeks to a 1 month).  I certainly know where the developer is coming from, though.  You eat enough of your own bad code, or someone elses, and you avail yourself never to let such filth enter your coding projects again.  It’s never that simple.

Finally, he laments on how he doesn’t know what is best; having the git-r-done for demo’s and having the code her rights for the actual software… thus you need a developer who is extremely experienced so they intrinsically know when they need to do both.  To me, software is hard, hence experience being the only thing I’ve seen that makes anyone good.  I’ve seen tons of geniuses setup to fail, and they either fail to recognize it, or choose to ignore it.

The lesson here is that demo’s are extremely important in startups.  If you have something to prove, aka validate you are making progress to your investors, you need to ensure you can give one well.

How to Create Effective Code Demo’s

Working in the agency world, Cowboy Coding rules.  There is no way I can see Scrum working there the more I do it.  A lot of your “builds” are in fact demo’s; demos you show to your creative director or even the client.  Some, however are specifically created for certain situations such as client meetings, conferences, and most importantly sales meetings.

The client meetings are easy; if you know something is broken, you fake it.  For example, I’ve had situations where the back-end wasn’t done, or was but was flaky as hell.  So, I just used a local XML file instead and hardcoded a link to it instead of the server.  This accomplishes 2 things.  First, I can ensure the demo will always work when getting that data source.  Second, I don’t have to worry about it and can focus on improving other areas, thus making a better demo.

The conferences are a whole different ballgame.  There are many different opinions on it, but here are mine based on experience.  If you want to succeed at a conference, fake it… all of it.  A lot of the big software companies do it all the time at conferences, but never let on… that is, until a blogger spots it.  A lot of the suits/bob’s/c crowd who are watching don’t read those blogs, though, so it’s all good.  If someone technical body checks you, honestly explain that it is a work in progress, and you are seeing a demo.  Make sure you articulate it in a matter-of-fact way.  This makes the questioner look silly for assuming it was any other way, and takes the expectations of the audience off of you.  Why fake?  I have NEVER in my career had a dependable server when presenting.  I don’t just mean a back-end, I mean reliable internet.  I’m honestly not trying to be cynical, but Murphy’s Law always seems to be in major effect when presenting: if something can go wrong with your connection, it WILL go wrong.  So, you fake all server connections.  This also allows you to demo ANYWHERE, including on an airplane, at a bar (yes, geeks bring their laptops to bars), or when a nuke releases an EMP blast at your ISP… yet far enough away that your laptop still works.  Most importantly, since you don’t have to worry about the back-end, you can focus 100% on your message, of showcasing the software.  Yes, it’s fake, but the audience will hang the grace of your words because your confidence will show through.  Keep in mind, it may not be you presenting, but your boss.  If your boss trusts you, and you’re confident, then they can be confident.

Sales meetings are about the same as conferences, except you usually have a lot less prep time, and thus anything “real” risks actually meeting your deadline or even sabotaging the sales call.

Most important of all, the best demo’s are ones that you and your team are ready to do.  If you’re not ready, don’t do it.  Granted some demo’s, if not done, ensure you’re company will cease to exist.  However, I’ve had some where I had to demo to my client progress of software.  While I lost trust extending it a week, I gained it back when my software worked like I said it would.  I’ve also had demo’s where I knew I was going to fail, and when it did, I drove home a major “I F’ING TOLD YOU SO!!!” to the sales guy who henceforth trusted me.  Again, the point here is if you’re faking everything, you can do it faster.  Even if you garner more time to create a great looking demo because you don’t have to worry about the “real” part, you still need to ensure it goes off well.  If you assume everyone who see’s your demo knows jack about code, then all you have going for you is visuals that “look” like something is working.  Make it count.

Demo’s and Scrum – Round Peg, Square Hole

So how does my version of a demo fit into Scrum?  As I’ve found, it doesn’t… at all.  This last sprint was one of the hardest for me.  The whole point of Scrum is that you end up with user stories (features) from the backlog going into your software, and that they just magically work well on their own, and with others.  That means at the end of every sprint, you should technically be able to demo real, trackable progress.

Any Software Developer, however, knows that some functionality can be done in 2 ways: the right way or the wrong way.  A lot of times the “wrong way” is the “fastest way”.  For demo’s, if you want to really impress someone, you put it chock full of features that you know will sell them on how cool it is.  Again, demo’s only have to work for 30 minutes… after that, you don’t care if the code is crap.  A lot of times, the demo is a separate build entirely that’s thrown away.

In Scrum, you don’t “throw away” code.  Granted, you re-factor like crazy which is in essence throwing away code, but the key is you are not throwing away effort whereas in a demo, I’ve had an entire week which I knew was going to be spent writing code for just a sales meeting that may or may not make the sale, and the code I was writing would never be touched again.

So, the whole concept of tackling a set of user stories and defects for a given sprint with the demo looming over my head felt 100% WRONG.  It goes against every experience I’ve ever had, both in agencies and in software shops, at creating demo’s.  If someone I’m demoing to understands Scrum, great, but that never happens… if they do, then it’s not a demo, it’s the Friday UAT, and they are invited; 2 ENTIRELY different things.

I made sure both my boss at Enablus and the stakeholders at the startup knew I was extremely unhappy with continuing on.  I totally wanted to create a separate build, and spend an entire week on just getting the demo ready.   Less risk, and more control.  The suggestion was echoed once, but as we made progress and the software stability solidified, we became a victim of our own success and the idea was scrapped.  In fact, the only time I was working on tasks not related to my assigned user stories and defects was the day of the demo itself.  Granted, I still documented these as unplanned user stories / defects, but the whole thing majorally stressed me out.

The whole point of faking things is inspire confidence in you and your code.  You have control over what you are creating, and can focus on the concepts you’re trying to sell in the demo.  This spits in the face of Scrum and software best practices such as unit testing.  It makes you sound like a hypocrite who only does them because you’re told to, but you don’t actually agree with them.  The conflict of interest is determining if your audience someone who understands Scrum and the software development process or not?

Going with business as usual felt the exact same way as it did in an agency when you’d show what the designers and developers were working on.  The designers would show 2 hours worth of work, and those in the meeting would go, “Wow!”.  The Developers would show a week’s worth of work, but because no one could see anything visual and they didn’t understand how code works, they’d have the perception the developers made little to no progress, and worse, that the developers perceived themselves as making progress when in fact they apparently did not.

Basically, I’m operating on faith that the investors knew how Scrum works, and recognize that not only was the software being demo’d real, but there “weren’t some additional bugs to be worked out before it’s done”.  If you read Martin Fowler’s discussion on an “The Adaptive Customer“, it really implies that you’ve sold the customer on your process.  To me, this implies the customer recognizes the iterative process you are using, and can discern between a fake demo and real software because they are actively involved in the process.  Most importantly, they can appreciate the effort, and recognize hopefully clearly where their money went.

In the end, I’m convinced the traditional demo does not fit into Scrum.  Instead, you either need to inform those being demo’d to that it’s real software as of right now, or only demo when you are ready.  That last part, again, would never fly with some of the sales teams I’ve seen that sell shit that doesn’t exist, and you have a week to make something that somehow magically works so the sales team can demo it, and sign the deal.  That in itself, sabotages the whole Scrum process because that means you lose a week of a developer’s time, and thus skew your burn rate (the rate at which your team can complete user stories in a period of time).  To me, the best suggestion is to outsource the demo to a contractor, or educate your sales team on how Scrum works so they can sell reality.  If selling reality doesn’t work, because your customers are accustomed to “promise the world” sales teams, then why are you using Scrum?

Burnout

Another side effect of demo’s is that they tend to cause burnout more quickly, at least for me.  As you work towards the crescendo of the demo, your stress level increases.  At the end of the sales meeting / conference, you have to take some time to unwind.  However, there is no “un-winding” in the Scrum I’m doing.  The planning meetings we’d have every other Monday used to be kind of slack as you’d do some R&D for time estimations, and get your affairs in order to ensure you could focus for the rest of the sprint.  The post UAT sessions every 2 weeks were pretty slack afterwards as you were waiting for the planning meeting the following Monday, and you probably spent the rest of the day handling un-finished user stories / defects with reduced gusto.

The past 3 sprints, however, have reduced this.  Because of the regression, I’ve been using those times to either increase my test coverage, learn how to write better test coverage, and “fix broken windows“.  That’s all well and good, but even with a 42 hour work week (my average), that doesn’t quite work with a demo.  The traditional software problem of being relaxed in the beginning, and spending a lot more time towards deadline/demo time occurs, and suddenly burnout becomes more of a potential problem.

Now, theoretically, being a contractor should make this easier.  If I don’t want to work on a given day, I shouldn’t have to because I’m my own boss, right?  …well, not really.  We still have our standup meeting every day at 1 pm est / 10 am pst.  I still need to give a report of what I did, and what I plan on doing.  Regardless, some days I just had life get in the way, and didn’t get as many hours in as I wanted.  Other days, I’d get in a ton as well as knock out a bunch of tasks so it would even out.  Aka, some days I’d have errands to run, or was just burnt out, and would only do 4 to 5 hours, whilst other days, I’d get in the zone and do 10 to 12.  In the end, it evens out.

While I’ve enjoyed Scrum because my Sprint’s all planned out, I know what I’ve committed to, and no one is constantly pestering me with new stuff, the demo really threw a kink in things.  Rather than being stressed about my bi-weekly UAT deadline for my given user stories, I was stressed for 2 sprints with the board meeting looming overhead.  There are tons of blog entries out there that talk about how you recognize and solve burn out.  For me, it’s pretty simple:

1. stop working
2. turn off the work computer & my cell phone
3. go do something else like playing games

In places I’ve worked in the past, I’ve seen managers who can recognize it as well.  Some would just send you home.  This is rare, though.  I get burnout more than most because I pour my heart out into what I do, and any a minor non-reciprocation of my perceived effort really tires me out.  In fact, I get burnt out at least a few times a year.  I’ve been able to recognize it, and rather than fight it, I just go do the above 3 solutions, and it tends to get fixed faster.  That’s all well and good, but the problem with Scrum is that it doesn’t “stop” because you’re tired.  Missing a day negatively effects your burn rate.  Because burnout may not happen for 3 months, you can’t necessarily plan for it either.  I’m sure my project manager would say “it evens out”, but if I were to run an Agile team, and I recognized one of my developers was burnt out, I’d say to hell with it, and just let the backlog of user stories not deflate as quickly for that particular sprint.

Another thing that makes it more of a potential problem is startups since they tend to be more stressful.  I’m really really really spoiled in this case.  I’m not financially invested, and won’t lose my shirt if the startup fails.  That doesn’t really matter, though.  To me, this is MY baby, and I’ve accepted ownership of making it succeed.  I feel personally responsible for everything that goes wrong, and am 100% endeavoring to succeed.  While I’ll get nothing for stock options when if/when they do succeed, the satisfaction of working on a kick ass product, hopefully having the opportunity to demo it at conferences, and having a major success under my belt is what drives me.  The software can help make the world a better place (I think) as well.  That helps me sleep at night.  I play to win, and give it my all, and since working on products has more risk than services, there is a lot at stake here.  I know it, and it adds to the pressure.  I wouldn’t have it any other way, though.

Again, this isn’t related to other reasons; developers getting sick, having a doctor’s appointment, or vacation.  Those 3 things for example, you can make up for in increased time, or working on the weekends.  Burnout, however, is usually only solved by NOT working.  Not sure how to resolve that in the schedule, but for now, I don’t have to, the Project Manager does.

Feature Juggling – Resource Issues

There are a few advantages of Agile from a business perspective.  One is that you can change requirements late in the game to adjust to a changing business and/or technology landscape.  If your customers are suddenly using a new financial reporting mechanism, you can add this as a priority user story in the next sprint.  That doesn’t work in Waterfall.

Another is assessing progress.  As you and your team mark off user stories and defects, the burn down is updated.  As you compare it with the past burn rates, you can project with more confidence what your team is capable of doing.  If one particular meta-user story isn’t projected to getting done anytime soon, yet is important, you need an additional resource.  In our case, we needed reporting done for the demo, and for launch of our product.  As you may know, Flex has some really nice charting controls, but also has the rich graphical abilities to create custom charts as well.  Didn’t matter… my co-worker and I were overly busy on other sections of our app.

Worse, a very important configuration screen was needed for 2 reasons.  First, it’s needed to help the server team write a good middle tier for the hardware.  Second, that was one of the areas of the original design comps that were the least defined, since we still don’t know exactly how it should work.  Iterations in software are great for “figuring” things out quickly.  Yet, it didn’t sound like my co-worker and I were going to get there either in a reasonable time frame.

Even worse, Flex is still niche.  While it’s been great over the years seeing Java and other traditional developers pick up Flex really quickly, this still hasn’t resulted in a market saturation of able bodied developers.  Flex Developer contracting rates are still high, consulting rates are still insane, and the Flex Developer body count is low.  Those that do exist are usually “busy”.  While I’ve seen in increase the past 3 months of Flex & Flash Developer availability, their rates haven’t lowered.  As a development manager, you’re left with 3 viable solutions.  You can either train your existing developers, hire a developer from another technology and train them, or use another technology you already have competency in.

In our case, we’re a startup so can’t just go burning through cash on additional contractors and consultants.  I’m speaking for the leadership here, but I’m pretty sure we’re also firm believes in the “small, agile teams”, so in this case, less is more.  That makes the options go from 3 to 2.  Learning Flex, while great, certainly reduces the time in which satisfactorily results can be achieved.  For a software shop, that is totally fine.  For a startup, time is the driver especially when you have many other facets you need to put in place beyond just the software, such as hardware, hosting, fulfillment, support, and processing.

In our case, those 2 sections were brought out of the Flex RIA and into HTML.  The traditional server-side developers can be setup to succeed, and with the designer’s help, we can integrate it into the existing brand.  I begrudgingly agree with reporting, and disagree with configuration.  I really feel that it’ll compromise the user experience.  There is nothing I can do, though, but what?  That’s right… code faster.  From a pragmatic point of view, it’s better to have those sections working than not.  With a given timetable, a given budget, and a given set of resources, you do what you have to do.  This’ll ensure we continually eat through the backlog, although, I don’t think Scrum has a cost structure setup for user experience.

Feature Juggling – Performance Issues

The point of allocating a certain time length to your sprints is to have a system of measurement.  These metrics can be used determine how your project is doing, and can be used to project “when you will be done”.  Projections are only as good as the data, so Scrum IS a process that requires you to follow it to ensure you have good data.  The theory goes that if your team completes 20 user story points consistently each sprint, each Sprint lasting a month, then doing the math, your team can complete the remaining 60 user stories in the backlog in 3 months.  I’ve found the minutiae of acceptance criteria, refactoring, and platform limitations can greatly skew this number.

For example, I did a POC to determine if we could do a few challenging things.  After looking at the initial wireframes and design comps, and I made the recommendations we spend a week or two on 3 specific areas to determine if they can even be done.  This was important because the reason of using Flex, and Flash Player in general, was based on around some of these compelling features.  These proofs of concept would ensure we could do what we really wanted to do, and to a well performing degree.  While the initial proof’s of concept proved as always that anything can be done in Flash Player if you try hard enough, to what performance level is in question.

The devil is in the details as they say, and as we found, we started to hit some bottlenecks, some un-solveable from a programming perspective.  One thing I’ve learned in Scrum is that there need to be 2 criteria for completing a user story.  First, a timeout on your task.  If something takes too long, you re-assess where you are at.  If no immediate programming solution can be found, and your stakeholder does not wish to allocate any more time to the user story, then the designer needs to design an alternative solution that is easier to code.  In our case, I have 30 minutes for a given task.  If I make zero progress, we usually move on.  If this happens repeatedly (like 3 sprints) we usually punt.  My lack of ability for certain user stories / defects creates more work for the designer to create alternative solutions.

This isn’t so black and white with performance, however.  What is the acceptance criteria?  How “well” should something perform, and to what degree?  We had one feature that was consistently causing performance issues.  It was one of those things that if you just removed the feature entirely, caching of images, the ENTIRE app just “felt” better.  Because we had long gone past the cut off period, the user story was in a state of purgatory.  It wasn’t a user story at this point, but a defect, and thus only worth 1 point (vs. 5 for the hard user stories).  Additionally, it was never prioritized above over existing user stories or newer defects.  It just became “a fact of life”.

The point of building software in iterations is to try something and see how it works.  If it works, great, add more things.  If it doesn’t work, try something else.  This implies a set time, again, the length of a sprint.

But what if you recognize something doesn’t work… say… 5 sprints later?  While both me and the server-side developer had spent a good amount of time on getting the feature to work, ultimately it doesn’t add much to the user experience for what it costs in performance.  Utilitarianism at work; the pain of the CPU hit for multiple SharedObject.flush calls vs. instantaneous images refreshes isn’t worth it.  The responsiveness of the app, with an already quick image refresh from a fast Amazon S3 + server-side caching makes it quick.  Additionally, with some clever cleanup & optimizations of Ely’s SuperImage, and voila, you still have wicked fast images.

I bring this up, because if you read about Iterations online, it implies that you are trying things during a sprint, and assessing if they work or not during the sprint; aka, a SINGLE sprint.  I’ve found 2 cases where things took 4 sprints or more to figure out.  One had to do with performance of the Flash Player’s saving of Flash cookies, and the other had to do with our team’s collective agreement on a design iteration looking and working like we wanted it to.

What I don’t know is how this affects your burn down.  Is it really a satisfied user story if it you take it out?  Technically adding a new user story, or modifying an existing one still counts as features in the backlog, and completed user story points.  What it doesn’t allow for, however, is the “figuring things out” in the above equation of using your points per sprint to determine completion.

Conclusions

I’m still convinced demo’s don’t work in Scrum.  I’d say, if you are demoing your software you need to engage those who you are demoing to on how Scrum works so when you see working software, it is in fact working, what they are seeing is reality, and they have an a clear understanding of what’s left.

It seems burnout can greatly affect your burn down metrics.  Since you technically need to not work to fix it, the only thing I can think of is factoring in burnout to your overall projections.  If you feel you may be burning out, the only thing I could think of to do is ensure you have less user stories committed to for a given sprint.  That way, you’ve accurately set expectations; the data is still good, and the math of story points per sprint will work itself out.

Resources can be really challenging to juggle.  If a particular feature is taking one developer too much time, you’ll have to shuffle the tasks around so another developer can take it over.  If you can’t hire another developer, or another existing developer doesn’t know the technology, your designer will have work with the stakeholders to create a new/modified design that’ll work in the new technology.  It may seem it obvious, but I’ve seen this happen on a few projects where certain portions are done in HTML vs. Flash strictly because of resource issues.  The thinking goes it’s better to have something vs. nothing.  While everyone would prefer the better user experience, even having something vs. nothing is a better user experience.

Finally, while iterations are typically akin to sprints, you may not necessarily determine if a piece of functionality, or a design will work for a few sprints.

Hopefully by now you’ve noticed a pattern in my articles where strong design leadership can make or break a project, design being the visual kind, not the architecture kind.