Table XI Blog


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

How Docker and Kubernetes make infrastructure almost instant

When we started experimenting with Docker and Kubernetes, we were just looking for a more efficient way to stand up our applications. Traditionally, it’s an infrastructure or operations team’s responsibility to make sure every dependency an application needs to run is set up the server, and that none of them are in conflict — and then continue to ensure that throughout the life of the system. It’s also their responsibility to figure out which server the application need to go on in the first place.

Read more

Why do user research? To build products people love

Too many companies realize why they should do user research too late, when they’ve already missed out on opportunities to make product development more effective, deliver high-impact launches and capture market share.

Read more

Choosing between healthcare software companies? What to know

There’s always a learning curve when any industry turns to healthcare software companies, but it’s a particularly deep chasm between tech and medicine. Both sides are highly technical, but that’s where the similarities stop — different cultures, different languages, different expectations about the role of software in healthcare.

Success depends on building effective bridges.

Read more

Learn Agile with LEGO

At Table XI we’ve found that the best way to demonstrate the agile process and the complex relationship between the client, the software developer, and the project manager, is to roll up our sleeves and have some fun. We designed a hands-on, collaborative LEGO game that allows participants to experience an agile development project in a short, two hour window.

Read more

An Agile Approach to Developing Teams

Business man bending over backwards while looking at his computer.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

Learning Agile with LEGOs: A Chicago Ideas Week Event

People playing with Lego blocks at Chicago Ideas Week.During this past month’s Chicago Ideas Week, we went back to the building blocks to teach Agile methodology—literally. We hosted 40 people for “Learn Agile with LEGO” at our office, where teams built “products” with LEGO bricks using the Agile process, and got to relive some childhood fun along the way.

Read more

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

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

The Boring Software Manifesto

XI To Eye LogoOver 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 

Software Is NOT Like Building a House

A house in construction inside of a circle-backslash symbol.Our friends at Wired recently posted an article in their opinion section claiming that building software should be just like building a house.

No, no, no.

To be fair, this was just an opinion article and not part of the actual journal. But in my humble opinion, the article was wrong on many counts (and let’s just ignore the writer’s rather cheeky sentiments like, “Writing code without thinking is a recipe for bad code.” That’s just insulting and not terribly insightful...)

Writing software is not like building a house. This is an unfortunate metaphor that will confuse and frustrate new clients unfamiliar with custom-built IT software projects.

True, building a house, much like building custom software, does indeed require some upfront design, an architect, precision tools, and skilled people who are good at their craft. But that’s where the analogy ends—they are just loosely related concepts.

With custom software projects, expecting—and, frankly, embracing—change is a critical part of the process. Often what a client requests is not, in fact, what they want or need. Only after testing and playing with a system do the real requirements emerge. A critical part of agile process is adaptive planning, where feedback is welcome and priorities can change. This is the power of the agile process.

If you want a recipe for failure, go ahead and document every last detail of a project before ever starting development. In this waterfall method, teams will spend days, weeks, or even months in “analysis paralysis,” drawing up architectural documents, requirements specs, and designs before writing a single line of code. These documents will be written in stone and clients will go through a lengthy review and signoff process. The supposed goal of this spec-driven exercise is to make sure those rascally developers follow the plan and do exactly what they’re told, essentially commoditizing the process and eliminating all creativity and innovation. It also removes the ability for clients to react to feedback or change their minds, at least without an expensive change control process.

This is a surefire way to encourage finger-pointing between development teams and the customer. Not to mention, it will waste significant time and energy, and a lot of the client’s money.

Agile Manifesto

Trust me, there is a better way.

The agile process starts with an element of upfront thinking, design, and planning. No (successful) software team jumps right into writing code on day one. For example, at Table XI, we always begin our new projects with a Project Inception, allowing us the opportunity to brainstorm with our clients while building a shared understanding of the project requirements and product vision. This upfront planning is a vital first step, but as the Agile Manifesto reminds us, embracing change is more valuable than simply (or blindly) following a plan.

With that common vision and initial plan in place, we start developing the product iteratively, exposing progress, risks, and working software as we go. In this way, clients get to visualize progress NOT as a drafted spec document, but as actual functioning software that demonstrates real business value.

Through a constant feedback loop the customer can alter the direction of the project to align with their changing priorities and business needs. This level of control and quick response to user feedback allow for more rapid development and significant reduction in waste in the development process.

This does not mean that the agile process doesn’t encourage specs or documentation. Indeed, that level of detail still plays an important part in the process. But spending time in a heavy upfront specification stage will not lead to success for any client in software.

Now over ten years old, the Agile Manifesto is still relevant. And unlike building a house, a software project values:

  • Working software over comprehensive documentation
  • Responding to change over following a plan

The “building a house” metaphor is inaccurate at best and damaging at worst. People who go into a custom software experience expecting this behavior are just setting themselves up for life in a money pit. And no one wants to live in a house like that.

Graphic source: The Working Group


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

Table XI

328 S. Jefferson St.
Suite 670
Chicago, IL 60661


Give your team new problem-solving techniques with our innovating workshops and check out our event series.

GoodFirms Badge