Planning Meetings

I don't know anyone that enjoys 8 hour planning meetings. I used to find them useful for getting the entire team on the same page but it's painful. Now I prefer something more scrum-ban style and hold weekly 30-45 minute planning sessions. Just enough to fill out the backlog for a week or so.

Reality Check

Agile doesn't alter reality. I think it just helps expose it. In the end some of the variables you have to work with are still the same: people, time, and scope. If your product owner sends out an email telling the team to work harder to hit a deadline because scope is no longer negotiable ... reality check. If you uncover some technical debt that makes what you thought would take about a day to take more than a week ... reality check. At each hurdle I've encountered I make sure to take a step back, unemotionally embrace reality, looks at my choices, and then more forward.

Fine-grained or Coarse-grained User Stories

Having gone both extremes when fleshing out a backlog I now lean towards coarser-grained user stories. I found that while finer-grained stories help expose what's exactly being worked on, it's at the cost of a cluttered backlog which makes it more difficult to determine the progress of overall business value. The downside of coarser-grained stories is that tickets may hang around longer than you'd like and look stagnant. I think it's an art and I find that regular communication through daily scrums and team chat rooms helps keep an eye on detailed progress.

Defining "Done"

I used to think I was cool wanting a firm and awesome definition of "Done" for a user-story. Code complete, design reviewed, unit-tested, QA'd, etc. Don't get me wrong, I still like the idea of Done. In a recent project we didn't have UI designs for a while. I defined Done to include design of course. But after a while the design bottleneck caused the list of in-progress tickets to grew unbearably. Tickets were code-complete and QA'd, but the designs just weren't applied yet. It was difficult to quickly see how the team was doing. I later decided to remove the design requirement for Done and created separate chore tickets (in Pivotal Tracker) to address designs later. When design was no longer a bottleneck, it was added back as a Done requirement. It wasn't perfect but in that situation my desire to improve flow and process trumped my desire to have concise and perfectly Done tickets.

I can't claim these lessons as absolute fact, but I hope someone fines them helpful. Happy Agiling.

I think TDD is great when you know what the code should do. When I'm writing parsing code or something else very utilitarian I definitely prefer to write the tests first. As a Flex/Flash developer, most of my code is directly for the UI, and often I find that I'm not entirely sure what my code should do right away. I'm becoming a big fan of the Presentation Model pattern, but even with that, I find that it takes exploratory development to determine exactly which component should do what and which logic should go where.  I found it very burdensome to update both the regular code and tests step-by-step . Not being a TDD expert I could easily be doing something or interpreting something incorrectly. Or perhaps I'm just lazy.

I've decided, at least when it comes to UI development, to follow a looser Testable-driven development technique. As I'm fleshing out my component logic, I constantly ask myself, "Is this code testable?" or more generally "How will I know if this works?" This primitive technique gives me the freedom to write exploratory code while helping to reign in potential magic logic. I then write tests once things have settled down, refactoring any logic to make things more testable as necessary. This technique also fits my style of coding where I like to sketch out logic with small tracer bullets.  It definitely takes some discipline to think about the testability of the code, but so far I'm much more comfortable with testable-driven development for UI work.

Here are some guiding principles:

• The view code should reflect how you talk about the application with the entire team.
• The view code should reflect how you interact with the application.
• Repeating yourself can be a good thing.
• Components and events should be contextual.

Let's way we have an application that manages contacts. There's a list of all your contacts on the left. There's a list of recent contacts on right right. The selected contact's detail shows up in the middle. There is also a Twitter feed widget in the contact's details. Here's a wireframe:

Here's how I would create the view package:

com.foomonger.contactmanager.view.ContactDetailsView
com.foomonger.contactmanager.view.contactdetails.events.ContactDetailsEvent
com.foomonger.contactmanager.view.contactdetails.TwitterFeedWidget
com.foomonger.contactmanager.view.AllContactsView
com.foomonger.contactmanager.view.allcontacts.ContactItemRenderer
com.foomonger.contactmanager.view.RecentContactsView
com.foomonger.contactmanager.view.recentcontacts.ContactItemRenderer

So what did I do? I created components that reflected the wireframe. There is a component for each major section (all contacts, contact details, recent contacts). I named the Twitter component "TwitterFeedWidget" even though I thought the "widget" part was dumb but that's what the product owner and overall team calls it. I also created a ContactDetailsEvent class within an "events" package specific to the ContactDetailsView component. That may be a bit extreme for some people, but I find that it helps me keep track of the purpose and scope of view events. I also created a ContactItemRenderer for both the AllContactsView and RecentContactsView. Even if the code was identical in each item renderer, I prefer to keep them distinct instead of having a common one in a generic "itemrenderer" package. I argue that what I lose by repeating myself I gain back in maintainability. If there was a common ContactItemRenderer, after many months of new feature development with several developers it'll be easy to lose track where it's used. If the item renderer has to do something different in one particular case you can of course add properties and states to keep it multipurpose. However I've found this to be regression prone. If you have distinct contextualized components, you can be more confident that a change will not cause regression elsewhere.

I used to always look for even the slightest resemblance of a pattern and abstract all kinds of code into shared components. But I've realized that developing an application is different from developing a component library or a framework. In a component library you can have a generic color picker. In a framework you can have a generic "itemrenderer" package. I'm not saying you can never do these things in an application, but I am saying that I think application development should be very (domain) specific.

Document areas to refactor. When you have to take a short-cut to hit a deadline, first of all comment the code and then create a ticket to address the short-cut in another sprint. I also suggest tagging the ticket as "technical debt." This will give your team visibility into the amount of technical debt that is accrued.

Include refactoring into story estimations. If you know that a story would be best implemented if you refactored some code, don't start off by giving an estimate that assumes you'll use a short-cut. It can be natural to people-please and say things can be done sooner but try to avoid that and keep in the mind the goal of writing high quality software which includes refactoring.

Clean up the small things when you see them. Refactoring doesn't have to be a clean sweep of the whole house, it can be just a good habit of picking up things along the way. I wouldn't recommend rewriting significant logic for fun, but if you're in some code and find that a minor change would significantly improve readability then it might be worth the few minutes to do the cleanup.

Break down large refactoring changes into manageable tasks. You'll never have the time to do that gigantic overhaul of that terrible reporting system (or what-have-you) all at once. What you can do is break it down so that the work can be spread out across many sprints. This effort can be complex so I suggest starting by creating a task to outline all the changes that should be made.

Evaluate and convey the business value of the refactoring need. It's likely difficult to find a product owner who will add a refactoring system story into a sprint just because you tell them it'll make the code better. There's no apparent business value in that reason.  Think of the issue from the product owner's perspective and consider the "so that" part of the system story. Ask yourself, "Would it improve system performance? lower technical debt? improve throughput? address the root causes of the growing list of bugs?" You may even find that the refactoring you wanted to do doesn't have significant business value and is just clean and maintainable enough the way it is.

One of the great things about agile development is the exposure and mitigation of risk. If a system needs significant refactoring then that's risk that the entire team should be mindful of. Refactoring can then be something that happens, not just something you want to do.

I think the same type of courage goes beyond the code and should be consciously applied to development overall. The goal of software development in business isn't excellent code quality after all but instead to meet some sort of business objective. For example, I think it takes courage to realize you've underestimated the complexity of a task and to come back to the product owner/client/manager and say "We screwed up and totally overlooked this when we implemented that. The consequences are this and that." I think it takes courage to say half-way through an iteration, "We just realized that we can't do all of this in time, but we can do this small part." This isn't anything new, and from my understanding good agile teams do this well naturally. I like to think of these things within the concept of courage because of the empowerment angle.

So while embracing courage within a programming context makes me more productive in writing code, I've found that embracing courage within an overall development context makes me more productive in creating business value. I can't say I do this all the time, but it comes to mind, at least subconsciously, with every hurdle I encounter. I think that in the face of imperfection, unexpected complexity,  and evolving requirements, software development needs more engagement and with more engagement, more courage.