Table XI Blog


Restructuring your organization? Treat your company like a product

In August, TXI launched phase one of a redesign of our internal structure and growth path with two major changes: a flexible career grid and a manager-supported organization. Ellen Brast, Talent Experience Lead, and Claire Podulka, Chief Delivery Officer, share their approach to organizational change at TXI.

Read more

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 

Table XI

625 W Adams St
19th floor
Chicago, IL 60661


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

GoodFirms Badge