All Posts in agile
We were full of ideas around here this past fall, in no small part thanks to October's annual Chicago Ideas Week (CIW). This year we served as the organization's technology partner, helping the nonprofit launch its new website, enhance its online ticketing system, and develop a ticket scanning mobile app.
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.
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.
Retrospectives 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.
The 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/
Over 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.
This year, for Table XI’s annual company retreat, the frozen shores of Lake Geneva and The Abbey were calling. Though it may not have been as lengthy (or exotic) as 2012’s week-long trek to Costa Rica, we still managed to fit a lot into four days.
Our biggest goal with our retreats is always to give our people the chance to get to know each other better outside the restraints of project teams and a regular workday. This has only become more important as we’ve grown substantially over the past two years, and it’s always enjoyable to see people who don’t cross paths on a normal basis hanging out playing Werewolf or putting together a LEGO Death Star. On Saturday afternoon, I noticed a card game going on involving a couple employees (both old and new), one of our contractors, and some significant others—none of whom had ever had much interaction with each other before. It’s great to see these kinds of connections form over the course of a long weekend. People also bonded over a trip to the Yerkes Observatory, Frozen Turkey Bowling (this is a real thing that’s exactly what it sounds like), meals both company-sponsored and not, and an evening of S’mores around a campfire.
The other point to taking these retreats is to give ourselves a chance to work on the business as opposed to in the business. During the days we broke our team into smaller groups for professional development and company planning sessions. In particular, we made a lot of progress around targeting our marketing and account management efforts and selecting the right tool for our delivery operations. We did a deep dive on our customer profiles, identifying key patterns and practices that will not only help us serve our current clients better, but also let us pinpoint client prospects we think will be a good fit with Table XI.
Finally, we went over the business’ finances with the entire company. This is always a key component for me, since our newer employees are often surprised and appreciative of this level of transparency and candor. I’ve always maintained that giving people the greater financial context for why we make certain decisions is crucial to the health of the company as a whole, since it empowers the individuals working here.
All in all, I’m happy with our Lake Geneva excursion and the progress we made on a macro level. Stay tuned over the next several weeks for some more detailed retreat follow-ups, including a shot of our new commissioned artwork “Eleven Tables,” and some pretty hilarious photo galleries and videos of people doing things like throwing frozen turkeys at bowling pins.
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.
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
Sign up for our monthly newsletter to stay up to date on the latest tech tips from Table XI and to receive exclusive invites to events