agile

Kicking off an Experiment in Agile Family Management

I became aware of the idea of taking the “Agile” approach to software development outside of a technical environment and into the family when I heard a talk Bruce Feiler gave at TEDSalon in New York City in 2013. Feiler identified some of the pain I experience as a parent. I feel like I am constantly on the defensive. I struggle to keep up with daily emergent issues. I don’t get to focus a lot of my time or energy on long- to medium-term goals for my family. Lack of communication between family members often leads to both parents and kids feeling out of control. Sharing information is too laborious and time-consuming. Performance of all members isn’t adequately tracked for admonishment or reward.

Read more on Kicking off an Experiment in Agile Family Management…

Successful Sprint Retrospectives: Tips and Tools

A sprint retrospective is a brief collaborative exercise that teams can do at the end of each sprint—typically as part of the sprint review meeting. Its purpose is to reflect on what happened during the sprint with the goal of improving the team, but there are other benefits, like building team chemistry, sharing knowledge, promoting a sense of team ownership, and having fun.

This post covers what’s involved in a sprint retrospective, touching on some “dos and don’ts” and sharing a few software tools that can make them easier—especially for remote teams.
Read more on Successful Sprint Retrospectives: Tips and Tools…

Agile + Scrum = More Effective Iteration Meetings

Do your iteration meetings drag on forever, include thrashing and tangential conversations, or seem generally unproductive? Being structured about agile iteration meetings allows the Development Team to stay on track and get the most value from stakeholders’ time. Read more on Agile + Scrum = More Effective Iteration Meetings…

Travis CI Now Monitoring Ceedling and Friends CMock/Unity!

We have updated Ceedling and release a new Rubygem to bundle the latest TDD counterparts, CMock and Unity, to utilize Travis CI to monitor the health of our tools at the ThrowTheSwitch GitHub organization!

Atomic Object has blazed the trail of bringing effective test-driven development (TDD) and continuous integration (CI) to C development for nearly a decade. When we embarked on this journey, very little (if any) support existed for the C language, so we rolled up our own.

  • Unity is a basic testing framework. It’s portable C, easy to configure, and runs on almost everything.
  • CMock is a framework that works with Unity to help you create mocks and stubs of interfaces to simplify testing.
  • CException is simple exception handling in C. It is significantly faster than full-blown C++ exception handling but loses some flexibility.
  • Ceedling is a build system that rolls up all the above into single Ruby gem!

Read more on Travis CI Now Monitoring Ceedling and Friends CMock/Unity!…

Balanced Team is Coming to Grand Rapids in 2015

Update February 2015: Tickets for the event are now on sale! Early bird tickets are available through mid-February; standard tickets will be available after that. Please visit the Balanced Team 2015 Grand Rapids website for more information. We’re excited you’ll be joining us. See you soon!

Many teams and organizations struggle with the question, “How can creative teams work together to produce valuable, validated outcomes in an environment of extreme uncertainty?” This is a tough question — and surely has no single answer — but it’s one that the Balanced Team group has been addressing head-on since 2009 through meetups, mailing lists, and conference presentations.

Balanced Team events have been held in New York, Boulder, Austin, and San Francisco in the last few years, and now it’s coming back to Grand Rapids. Brittany Hunter, Gail Swanson, Rick Harlow, Lane Halley, and I are excited to announce a Grand Rapids Balanced Team Summit on June 13 and 14, 2015!

We’ll be gathering around 100 multidisciplinary software practitioners with traditional design, business, and engineering backgrounds for two days of talks, fishbowls, and workshops. We’ll again be tackling the above question. Read more on Balanced Team is Coming to Grand Rapids in 2015…

Considering a New Methodology? First, Understand the Question

In Douglas Adams’s Hitchhiker’s Guide to the Galaxy series, an advanced civilization builds a supercomputer to calculate “the ultimate answer to life, the universe, and everything.” After millions of years of calculation, the computer finally gives its answer: forty-two. Despite being an advanced civilization, it succumbed to the pitfall of getting an answer without first understanding the question.

We often fall into the same trap. I once worked on a development team that practiced Agile programming. Every now and then the team would debate whether we were really practicing Agile, whether we should do more Agile, whether we should abandon Agile altogether, and whether we should adopt some other methodology. The debates centered on personal preferences and impressions of team productivity. Alternatives were suggested based on what the team had tried before and who had what certifications. Never did our conversations start with understanding what problems the various disciplines were designed to solve. Neither did we begin with the most important question: what problems were we trying to solve? We jumped straight to the answers without first understanding the question. Forty-two. Read more on Considering a New Methodology? First, Understand the Question…

7 Ways to Keep Your Big Project Agile

Most of our projects here at Atomic Object take just 2-6 developers. But sometimes we work closely with other teams that are much larger.

On my current project, we’re part of our client’s much larger team, about 20 people. The team started out small, and as we’ve grown in size, we’ve had to refactor our project management practices as well as our code.

Here are a few of the ways we’ve refactored our Agile process.

1. Keep Your Stories Small

At a smaller size, we were successful with having stories that were about a week or less in size. As we have been growing, these bigger stories have been causing us some pains. Lowering the maximum size of a story to 2 days in size has worked well for us.

Read more on 7 Ways to Keep Your Big Project Agile…