March 21, 2019No Comments

How to apply Agile thinking to diverse business problems

Agile thinking is baked into our brains at Table XI. We come up with an idea, we test it, and we pursue it or discard it based on the results. Just like with our products, we avoid going too far down one path before we validate that it’s the right one.

Read more

October 5, 2016No Comments

Why our project kickoff meeting is two days — with homework

You can trace most problems in software projects all the way back to the start. Maybe there was a large PDF of needs and requirements. A project kickoff meeting or call that had everyone nodding, but no one asking any questions. A set of goals for the project, but no understanding of how they support the goals of the business.

It’s no wonder things go off the rails — and yes, as a Rails development shop, we endorse that pun.

Read more

March 24, 20161 Comment

How our strategy inception found a future for The Wabash Lights

The Wabash Lights

As engineers and problem solvers, we like good ideas, but we like good ideas implemented even better. To help somebody coalesce their vision into something that's actionable — that’s a process that’s rewarding for us. Doing a strategy Inception gives us an opportunity to interact with people who are just ridiculously smart in their domain and to add tons of value by forming an actionable plan around their expertise.

Read more

November 18, 2013No Comments

An Agile Approach to Developing Teams

In the development world we hear a lot about the term “Agile.” In software this refers to an iterative approach to development that relies heavily on collaboration between cross-functional teams, feedback, testing, and continuous improvement. It's the approach that Table XI uses to design and build websites and mobile applications.

Read more

September 11, 20131 Comment

How to Run an Effective Retrospective

How to Hold a RetrospectiveRetrospectives have long been an important part of the agile software development process. The team should regularly take some time to reflect on what's working well, what isn't, and make any necessary adjustments. On most of our projects, we do a brief retrospective as part of each iteration planning meeting, which allows us to make course corrections along the way.

Recently, we've had a number of projects wrap up or launch major releases, and we've found it very helpful to take a step back and run slightly longer, more formal retrospectives.

  • Participants: Everyone involved in the project from initial sales pursuit through delivery + 1 Facilitator
  • Duration: 1.5 hours (we had 5-8 people retrospecting 3-4 months of development iterations)
  • Supplies: Whiteboard + markers, IdeaBoardz, video camera + conf call for remote participants (we use GoToMeeting)

Set Context (30 - 45 minutes)

Start by creating a timeline from the beginning through the end of the release. We're a software consultancy, so most of our timelines start with initial client meetings and a discovery phase that we call an Inception. For a product company, your timeline might start with a product manager researching new features. It's important to rewind all the way back to the beginning to make sure people are thinking about the big picture, and aren’t fixated on the last 2-3 weeks worth of work that may be freshest in their minds. It's also helpful to build a shared understanding among everyone in the group, since some team members may have joined or left the project at different times and not be aware of the complete picture.

This is where we use our whiteboard. The facilitator walks the group through creating the timeline and draws important events up on the board. We had one remote participant in one of our recent retrospectives, and she was able to follow along with a video camera pointed at the board. Common events you might want to call out include: when each person joined or left the project; the start of development; the first client showcase; the first time real users started testing; 3rd party integrations; infrastructure upgrades; data migrations; any changes in the client team; and major blockers that were resolved. On one project, we also got to track when the client brought us pies!

Individual Reflection (10 - 15 minutes)

Once everyone is on the same page, you can shift gears into actually analyzing what worked well and what didn't. I prefer to have people do this individually to allow everyone to come up with their own ideas and not be too swayed by the group. If you jump straight to group discussion you run the risk of having the loudest people control the conversation. Whether it's using pen and paper, Sharpies and sticky notes, or a favorite text editor, let everyone think on their own for a little bit. The categories we use are:  "What Worked Well," "What Didn't Work Well," and "What Do We Want to Take on to Future Projects?"

Group Discussion (30 - 45 minutes)

I'm as big a fan of sticky notes as the next person, but they have two downsides: they don't work for remote participants and they're a pain to clean up and transcribe after the meeting is over. Instead, we use a virtual tool called IdeaBoardz. It creates a virtual board of sticky notes that many people can see and interact with at once, and it lets you export the results to a PDF when you're done.

IdeaBoardzThe facilitator leads the discussion, asking people for their "worked wells" and transcribing them one at a time onto the IdeaBoard. Having the facilitator be the one transcribing lets the team focus on their discussion and also keeps some consistency and organization to the notes being captured. Conversation tends to flow pretty naturally as others agree or disagree with a point made and contribute their own points. The facilitator needs to pay attention and make sure everyone in the room (and on the phone) is getting a chance to talk. Move on to the "didn't work wells," and ultimately, establish a list of key learnings that you want to apply to future projects. This third category is where you get the most value from the exercise, so make sure you're capturing these nuggets of insight.

Capturing a list of “what we should do better next time” is a great first step in the continuous improvement journey—but it’s important that you make this your first step and not your only step. At Table XI, our delivery assurance team meets every two weeks to review the outcomes of these retrospectives and implement many of the changes suggested. We then plan to share a condensed version with the entire company at our monthly all-team lunches.

Are you running end-of-project or end-of-release retrospectives? Is there a different format that you've found works well for your teams? Have you found other tools that you like to use? Please share!

Image source: Håkan Forss http://hakanforss.wordpress.com/

Want to start visualizing your project risks?  Download our free Software Risk Management template

March 22, 20133 Comments

The Boring Software Manifesto

xitoeyeOver the years the term "agile development " has been co-opted to mean something it's not.  "Agile" does not mean the ability to change things at the last minute. In fact, when it comes to development, this kind of excitement is overrated. Sometimes boring is best.

In this edition of XI to Eye I present "The Boring Software Manifesto." In a Boring Software Process, we use continual steady improvement, automated test suites, and an understanding that requirements change to prevent surprises, and allow us to focus on the problems that are actually interesting. That’s it. No heroic measures needed.

Watch this short five minute video to hear more about agile development, the way I see it.

Want access to more articles like this?  Subscribe now to stay up to date on the latest from Table XI 

November 6, 2012No Comments

There Are Not 24 Hours in Every Day

A few months ago, a blog post made the rounds on Falsehoods Programmers Believe About Time. Here are two assumptions that could have gotten you into trouble this week:

  • There are 24 hours in every day.
  • Time always moves forward.

On Sunday at 2am, we rolled our clocks back an hour. One minute it was 1:59am, and the next, it was 1:00am.

It's common in web development to run maintenance tasks in the early morning, when server traffic is at a minimum. If you have a task that runs every day at 1:15am, on Sunday it ran twice. If you have a task that runs once an hour, on Sunday it ran twenty-five times.

Maybe that's better than what happens to a task set for 2:15am on Sunday, March 11th, which is to say, nothing. There is no 2:15am on March 11th. The day that marks the start of daylight saving time (not daylight "savings" time) has only twenty-three hours.

Of course, this assumes your clock is set to a timezone that participates in daylight saving time. You could have two servers operating ten miles apart: one in Indiana, one in Illinois, and if both were set to local time on Sunday, one had a twenty-five hour day, the other twenty-four. One minute their clocks were in sync, the next they were an hour apart.

This is one reason why building software often takes longer and costs more than expected. Not specifically because of timezones: DST issues are predictable, and there are a number of best practices to avoid them.

It's because there are always gotchas. If there are exceptions to "facts" like "There are 24 hours in a day," imagine how many exceptions there are to the rules that govern the web application you dreamt up three months ago. Assumptions like:

  • A user will never need to change their email address.
  • A product will never be assigned to more than one category.
  • Everyone will have a unique social security number. (One of my favorite gotchas comes from the California Department of Education, where they have over two hundred kids without an SSN named "Juan Garcia.")

There are exceptions to almost every assumption, and they often aren't apparent until you start writing code, or until you put the product in front of the customer. Seemingly simple problems tend to become more complex the longer we look at them.

This is why we don't sign fixed bid contracts, and why we don't reply to RFPs. It's why we start our projects with a thorough inception process where we ask "Why?" more in two days than your annoying four-year-old kid, and why we use Agile development to stay light on our feet so that we can juke-and-jive as requirements change.

And it's why we're skeptical whenever someone comes to us and says, "I already have the wireframes, I just need you to code it," because if we asked that same person how many hours are in a day, they'd swear the answer is twenty-four.

Want access to more articles like this?  Subscribe now to stay up to date on the latest from Table XI 

GoodFirms Badge