AGILE IN ACTION

So you're working on a user story with your pair, developing vertical slices and getting feedback from the tester and customer as you progress. You're ticking off the acceptance criteria as they're satisfied by the emerging functionality. Awesome! Everything is tickety-boo. Then the customer realizes that something is missing and asks for that something to be incorporated into the card. What do you do?

We create software by working inwards from the user experience. Maintaining focus on the users' perception of the system, we do just enough to satisfy the needs of the user rather than what we think is necessary or cool. On a regular basis, we come up for air to check context and avoid getting lost in the weeds. We decide which direction to go next based on where our client sees value and consider how we're going to demonstrate what we've created so far. We don't jump into unit land because trying to connect all the pieces at the end doesn't produce a good solution.

We're enjoying ourselves so much I'm wondering if it's illegal. We're working in a 4-man team with a new client (who consult for the Lean Enterprise Academy) and we're experimenting with some new techniques. Our goal is to create a product that is very kind to its users, so we're trying to stay as close as possible to the users' conceptual model and stop thinking like programmers all the bloody time. When we catch one another 'flipping' to techie mode we quickly 'flop' them back to user mode.

Don't bother managing your time. Manage your focus. We use pomodoros to sharply focus on achieving a goal every 25 minutes. If you focus on the activity you'll just wheel-spin and dig a hole. So focus on the goal - what you want to achieve.

If you're new to light-touch leadership you may find yourself focusing on the big events (standups, retrospectives, planning games, showcase, beer). However it's the little-noticed gardening work that happens over the course of an iteration that really helps a team work together and deliver effectively. Here's a few examples, some of which may be specific to our environment.

In our team, developers create the vast majority of the automated tests, whether they are acceptance tests, integration tests, or unit tests. They do this because they are story test-driven. They develop stories from the outside in, starting with the user interface and are guided by the acceptance criteria. The developers profile their code and create automated performance and load tests as they go because code has to be production-ready at the end of every 1-week iteration. Testers in our team do exploratory testing and they're free to pair-up with anyone, another tester or more likely a developer, to create any automated tests they feel are missing. The testers, however, add value to the team that goes way beyond testing. Working closely with the Product Owner they facilitate connection and collaboration with the customer, helping the team to empathize with users, understand their needs and appreciate value from their perspective. Working with the facilitator they help the team develop a conscience that is focused on the delivery of value and quality, while their continuous interactions within the team keep collaboration high.

Our team has been together now for about 15 weeks and things are going well. We've got a sustainable pace that's delivering value every week, our Product Owner and Product Sponsor are both happy, and everyone is having fun. So what's bugging me? 2 things.

All teams have blips. I sensed growing frustration in the team over the last few iterations - sniping, bickering, moaning, negative comments. Morale was starting to be affected. When the team norms were breaking down and a lack of respect started to emerge I decided to intervene and focus the next retrospective on getting to the root of the problem.

Typically agile software development combines incremental and iterative techniques to deliver functionality early and often. Many people believe that iterative development is the same as incremental development. In fact, they are different but entirely complementary practices for developing software.