Agile Chronicles #8: Demo, Burnout, and Feature Juggling

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

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

In this article, I 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.