With a little hard work and my secret development ingredient, you can be a better Agile Developer

Recently my fellow developers at Integrum and I took a survey that helped us assess our team with regard to our Agile practices. When taking the survey, and now reviewing it later on, I was struck by how many of the questions were related to a single concept. Many of the problem areas that can be uncovered by the survey, along with examples of one’s successes, come back to this one theme.

Are programmers nearly always confident that the code they’ve written recently does what it’s intended to do?

• Is there more than one bug per month in the business logic of completed stories?
• Can any programmer on the team currently build and test the software, and get unambiguous success / fail result, using a single command?
• When a programmer gets the latest code, is he nearly always confident that it will build successfully and pass all tests?
• Are fewer than five bugs per month discovered in the teamʼs finished work?
• After a line item is marked “complete” do team members later perform unexpected additional work, such as bug fixes or release polish, to finish it?
• Are programmers nearly always confident that the code they’ve written recently does what it’s intended to do?
• Are all programmers comfortable making changes to the code?
• Do programmers have more than one debug session per week that exceeds 10 minutes?
• Do unexpected design changes require difficult or costly changes to existing code?
• Do any programmers optimize code without conducting performance tests first?
• Is there more than one bug per month in the business logic of completed stories?
• Are any team members unsure about the quality of the software the team is producing?

What’s the common theme among these stories, and the secret to better agile development? Testing, testing and more testing.

The negative outcomes implied by some of these questions can be solved by testing. Spending time fixing “completed” stories? Probably something you could have tested. Conversely, the positive benefits implied by other questions can be had via testing. Want to make your code more inviting and easier to deal with for new team members or people unfamiliar with the project? Give them robust and well-written tests.

Estimating stories for an upcoming project is one of the more difficult tasks that agile teams have to perform. It’s never easy to determine how difficult it will be to implement a particular feature, especially when you’ve got different personalities, goals, and levels or experience in the same room. Unfortunately this all leads to people coming up with excuses and roadblocks which lead to inaccurate estimates.

I’ve identified seven problems pitfalls of the agile estimation process that I’m sure many other teams have experienced:

1) Estimating Time Rather Than Complexity

The point of estimating stories with planning poker cards is that you estimate based on the story’s complexity, not on how long it will take you to complete the actual feature. A story that’s an 8 is more complex than one that’s a 5, but it doesn’t meant that the 8 will take two days. It could take an hour or a week, it’s all relative.

Why it’s Bullshit
Estimates based on time make planning commitments difficult and velocities unreliable.

2) Not Estimating For “Simplest Possible Solution”

The “Simplest Possible Solution” is just that, what’s the simplest way that the feature described in the story can be implemented. When you get away from this you start going down all sorts of “what if” roads that always end up bumping up your estimate.

Why it’s Bullshit
Trying to guess what the product owner will want or what the completed feature entails is a waste of time.

3) I’ve Never Done That Before

There aren’t many software problems that haven’t been solved. Most of them are things that have been solved a thousand times in a hundred different ways. Adding complexity to a story because you’ve personally never solved that problem is shortsighted.

Why it’s Bullshit
Just because you’ve never done something doesn’t mean it’s complex. Lean on your team or network of developer peers to help solve these problems.

4) Estimating Stories In Excessive or No Isolation

Stories should be estimated in isolation, just as they should be written so as not to depend heavily on one another. However, developers will often try to assign too much complexity to a story because of assumed tasks or features that they think would accompany the story in a completed state. For example:

As a user I should be able to login
As a user I should be able to upload a profile photo
As a user I should be able to change my address

Some developers will see the first story and immediately think of the complexity of creating a user model, the controllers and views that go along with the entire registration process.

Alternatively some developers will see the last story and think “Oh I just need a form field for the e-mail address when the user is editing their profile.”

Why it’s Bullshit
The first extreme gives you chunks of related stories with too much padding that are never as complex individually as they are as a whole. The latter only (sometimes) works when the actual stories are extracted out into a bunch of very small stories, which has its own set of problems.

5) Gaming Velocities

If you’re looking to “guesstimate” how long a project will take to complete, you could grab some story cards and pick out what you think might be a week of work. If you add up the points assigned to those stories you’d have an estimated velocity. However, if you’ve padded your stories, or purposefully pick out a small number of stories, your project is going to appear much lengthier than it really is.

Why it’s Bullshit
You don’t look any better completing 50 points per iteration when you padded the hell out of your estimates than you do when you do 20 points per iteration with accurate estimates.

6) Always Assume The Worst!

There seems to be this mantra with some developers, “Always assume the worst!” When you come across a slightly vague story, let your imagination run wild and assume that the product owner is going to want the most complex solution possible.

Why it’s Bullshit
Remember, every story is a negotiation. You’re not going to know the exact details of the story until you have your planning meeting with the product owner. Often times the product owner would never have been able to dream up the solution on which you based your estimate.

7) Padding Padding Padding

Padding is all Bullshit
The problem of padding estimates creeps into nearly all of the above six issues. It introduces bad data early in the life of the project and makes every other step of the process unreliable. It’s almost always in an effort to cover one’s ass but it’s painfully transparent and reeks of amateurism.

Don’t pad your estimates.

I had a blast presenting at the recent Intel Developer Ignite. In my quick five minute presentation I mapped ten of Aesop’s fables to modern day software engineering challenges and principles. If you missed the event, or just want to check out my presentation again, here it is!

Age-Old Solutions to Everyday Problems

Big thanks to Intel and everyone involved for putting on a great event, I really enjoyed it and can’t wait to do it again soon.

One thing I’ve always heard about learning a new language is that you can’t consider yourself fully fluent until you can tell a joke. Telling a joke requires the understanding of homonyms and how words flow together. “So a guy walks into a bar…” sounds different than “A man enters beverage store…”.

When dealing with clients, it’s easy to joke about your client, but don’t miss an opportunity to prevent future missteps once you know more about them.

How often do you get off the phone with a client and immediately have a funny remark about some critique or issue they have mentioned. Typically this manifests itself when the client brings up an issue, that while important to them, is considered trivial by the developer.

Can you believe this guy!? I built out this whiz-bang feature and he’s just complaining about the font being too small!

The key part of this interaction is that you’ve now got a little insight into what makes this particular client tick. When you demo the next few features and he is unimpressed by the functionality, but comments on the spacing of form elements you should skip the joke and make a mental note for the future.

Once you can tell a joke about your client, before the interaction, and you have an “I told ya so!” moment with yourself or your pair afterwards, you know you’ve made it to the next level of understanding that client. Now, the next time you deploy a feature, discuss requirements or ask a question you can preempt the inevitable by accounting for those quirks and personal preferences of your client.

Instead of making a joke, make them happy, then you can both smile. ;)

Do you remember watching the FAIL Monster on Sesame Street? Never heard of the FAIL Monster? Weird, I’m pretty sure he was Cookie Monster’s cousin or something. He would pop-up and sing a little song about your failures and then at the end he would go crazy and NOM NOM NOM all of your excuses. The really strange thing is that when I grew up, I still saw the FAIL Monster, except he was all over, eating up everyone’s excuses, not just mine. When was the last time the FAIL Monster paid you a visit?

The FAIL Monster Is Your Worst Best Friend

When you first meet him you’re trying to figure out what this asshole is doing hanging out right after you really screwed up. You realize that he’s no good, but as time goes on, you start enjoying his company. He loves showing up because he knows there will be excuses aplenty.

Here are some situations when you might see him:

• You’ve messed up and can’t take responsibility
• The project is off track and it’s not at all your fault
• If only < outside agent > would have completed < task > on time
• You start using Fat Bastard’s circular logic to explain away your problems
• “I don’t have < resource > to do < what is right >
• You don’t write tests
  
  

Put the FAIL Monster on a Diet

Here is a quick guide to help you trim down your personal FAIL Monster:

1. Quit making so many goddamned excuses!
   
   

Stop making excuses for your lack of understanding, your irresponsibility, your lack of prospects and your shit attitude. Take the time to push yourself, learn a new skill, read a book, meet people, take a leadership role, achieve greatness and succeed.

You can make excuses for everything, the only thing they’re good for is feeding your own FAILURE.

I’ve been working at Integrum for nearly 5 months now. When I started, agile was a concept that I had read about, but never experienced in practice. I took bits and pieces of advice from books like Extreme Programming Explained and Practices of an Agile Developer but I had never really lived day-in day-out as a developer in an agile workplace. However, now that I’ve experienced the project boards, burn down charts, velocities and story workshops, I cannot imagine going back to the slam-your-head-against-the-wall waterfall approach from which I came.

What I Love

Project Boards – Nearly real-time visual feedback on the status of your project. Everyone on the team can assess your project at a glance and you can avoid long status meetings with middle management. Greatly increases accountability.

Stand-up Meetings – Quick, informative useful meetings that don’t waste people’s time. Social group pressure keeps people who like the sound of their own voice from talking for 30 minutes.

Daily Client Interaction – No need for ego-maniac project managers. Developers discuss issues with clients each day so that they can deliver the best software with the most value as quickly as possible. Challenges or roadblocks can be brought up almost immediately helping to prevent wasted time on either side of the equation.

User Stories – “Replacements for a conversation” as I always hear around the office. Replaces the need to confusing spec documents and misguided feature requests. These provide a way to ensure that neither the client’s money or developer’s time are being wasted.

Acceptance Criteria – It’s not easy getting quality acceptance criteria from your clients, but man is it worth it. Helps to make sure that what’s “done is done” and there are no disputes towards the end of the project about what is or is not completed.

Short Iterations – Allows the developer to focus on a set of the most important tasks for a short period of time. The client receives frequent demonstrations of the completed work and changes in course can be made very quickly. What was important 4 months ago during the original planning session might not be important this week.

Waterfall Development: DO NOT WANT!

Looking back on my last job where waterfall development was the norm, I can’t imagine how I got anything done. When I really think about it, I wonder how much software I wrote that was “right” the first time around.

Just as a quick list, here are some of the things I’ve grown to hate:

• Project manager dominated client interaction
• Long useless meetings
• Finger pointing and blaming and lack of accountability
• Waiting a few weeks to find out that your implementation is incorrect
• No way to tell what was actually “done”
• Wasteful spec documents
  
  

This Won’t Work For My Business

There are probably a lot of development shops that are humming along using long standing processes based on a waterfall model. A lot of people probably think that they don’t need to change because “if it ain’t broke, don’t fix it”. If you’re not doing agile your shit is broke!

A lot of managers probably think that this system won’t work with their employees. I can see this being the case if any of the following apply:

• You don’t trust your employees
• Your employees are morons (or you think they are)
• You think you need to operate like the status quo
• You can’t give up your control on the process
• Your clients suck
  
  

Agile Works at Integrum

Derek Neighbors has taken the time to produce a couple of videos outlining how agile is put into action at Integrum:

• Integrum Agile Workspace
• Integrum Project Board
  
  

Whatever the reason, agile works, like actually works, at Integrum. Is it the culture? The people? The atmosphere? The expectations? The clients? I can’t quite put my finger on it, but I can guarantee it’s not coincidental.

Last week at Integrum, as part of our ongoing effort to be the best, we had a retrospective/company-wide expectation meeting. We discussed our current processes, and outlined some new things we wanted to do going forward that would help improve everything we do. Even though we talked a lot about project boards and velocities, when it comes down to it, it’s really all about the people.

How to Earn a Gold Card

When I was in elementary school they had an ongoing school-wide program where students could earn “Gold Cards” and be recognized in the monthly assemblies. To earn a Gold Card, one had to be doing something benefiting others, without being asked. It could be something as simple as going out of your way to pickup some trash.

To be sure, a lot of students went around doing very insignificant, but still beneficial, activities all day in hopes of being seen by a teacher. The real takeaway however was the idea that the best type of deed is done where no one is watching. This is a difficult concept for a 4th grader, but the life lesson is outstanding.

Focus on the People

We talk a lot at Integrum about our process, our engineering principles, our goals, plans and expectations. But for every project board, velocity graph, client stand-up and piece of acceptance criteria, there is an underlying foundation of high quality people working together to achieve a common goal. Finding trustworthy, forgiving, understanding, motivating, helpful, challenging and comforting people to work with removes so many of the problems that these project management tools aim to solve.

When people live their lives being accountable to themselves and those around them, when they strive to do what’s right, even when it’s hard, and when they go above and beyond without the expectation of being praised, they can achieve great things.

I’m a fan of Flog. I like using it every now and then to make sure that I’m not getting too complex, trying to be clever, or setting myself up for testing failure. Typically these are things I look to my MILF slaying pair for guidance, but sometimes Flog can be just as good.

As a relative newcomer to Ruby, I’m still in the process of learning to identify code smells, poor design and needless complexity. I’m sold on the “readable code is better” idea so I try to keep that in mind as I’m implementing some piece of functionality. Over at Integrum, where I work, we pair on everything each day, save for the occasional sick day. Today I was working alone and was reviewing some code that my pair and I had wrote about a week earlier. It was complex, and I feel that we made a compromise with the idea that the “ugly” working code was good enough for what we needed at the time, but it was ugly enough that I remembered to revisit it.

Flog Builds Confidence

When I really started looking at the code my intuition told me that it needed to be re-factored. I knew that it could be improved, but I suppose I’ve been in the pair mindset so heavily since I’ve been here that I did not immediately jump in and fix things. However, when I ran Flog and saw the comparatively high scores for two complex methods I had been investigating, I had that supportive “yea I agree” feeling that I usually get from pairing. Flog helped push me over the threshold, from “maybe I should change this” to “this should be changed”.

This isn’t to say that I wouldn’t have changed it without Flog, but it gave me that extra confidence in knowing that I was on the right track. The direct benefit was that the code is now more readable and easier to test. Indirectly I’ve added another point to my mental Ruby experience score and will be more inclined to follow my intuition in the future.

Life treating you nicely? Everything going well at work? Having fun on the weekends? Feeling, comfy? Watch out! Sooner or later that warm blanket sense of security you get from your daily grind will start grinding on your happiness. If you’re not careful you’ll slip into a dip of comfort and satisfaction, risking little, gaining little.

If you’re heading towards that dip, or feel like you’ve been stuck there for a while, fear not, it’s easy to shake yourself out of it. Put yourself on the line and increase your expectations.

It’s easy to fall into comfortable relationships, comfortable careers, comfortable routines and lead a comfortable lifestyle. However, once you’re in that position you start to wonder where the magic went. You can recall a time when you were excited and things sparked your interest, now, they’re just boring old routines.

Imagine those exciting times. That time you spent dating, forging that good friendship, interviewing for jobs, meeting the new team, notice a pattern? They were all challenging times when you had to push yourself and risk something.

Risk being ignored, risked be disliked, risked being rejected, risked failing. You had to work hard and make things happen. Look where you are now, no risk, no challenge, no real effort.

Do yourself a favor:

• Join a local industry group
• Give a public presentation
• Attend a local lunch gathering
• Update your resume
• Start a new project
• Learn a new skill
• Make a new friend

Put yourself on the line, risk something, challenge yourself, flirt with the possibility of failure. The feeling you’ll get from all of this will tear that comfy blanket to shreds.

I’ve got a lot of ideas for various web applications, online communities and business opportunities. When I started writing these all down about a year ago I figured it would be something I’d stick with temporarily, but lose track of. Luckily I haven’t and I’ve managed to grow my list from a few concepts to about a dozen very well thought out ideas.

I really enjoy going through my list every once and a while improving, changing and evaluating my ideas, but I’ve recently been trying to actually act on them. I’ve found that implementing these ideas is by far the most challenging part.

Maybe I’m wrong but I think a lot of people feel like they’re particularly talented in some respect, but they just don’t have any good ideas. They’re great at wood working, but they can’t come up with an interesting design, so they don’t start. My advice to this person would be to come up with some design and build that table. Chances are they’ll find out that they’re not as talented as they thought, and they’ll learn things along the way. Add the benefit of the sense of accomplishment and it’s a great experience.

My whole point is, if you feel like you’re in a rut, or you’re unhappy with your job or you’re just feeling like you’re floating through life not really doing anything, grab onto an idea you’ve got and see it through to the end. You’ll be motivated to do it all over again, you’ll learn something and you will feel good about yourself.