Mobile Agile Development: Nine Winning Rules

Developers often complain that their project development environments aren’t “agile” enough. Sadly, they fell more under the “waterfall” methodology, which meant projects simply were taking too long to complete.

Farhan Thawar (@fnthawar) has successfully run an agile mobile shop at Xtreme Labs. At the conference, he gave a presentation outlining his company’s model for agile development. In general, the model for a successful agile shop requires iterative development, feedback, short cycles, transparency, and collaboration, said Thawar.

If you follow the rules of agile development, it’s very hard for your application to go off track, said Thawar. The following nine rules for mobile agile management are specific to Xtreme Labs agile development model. It has worked out very well for them – maybe it’ll work for you:

Rule #1: Everything goes into Tracker

People may communicate things to you via multiple ways: in person, via phone, email, etc. The Xtreme Labs team puts everything in Pivotal Tracker, so everyone knows what’s going on and nothing, ideally, falls through the cracks. Pivotal Tracker is a collaborative, lightweight, agile project management tool. (Disclosure: Xtreme Labs is an investor in Pivotal Labs.)

Rule #2: Priority rank all your tasks

Identify the ranking of everything. This is different than creating low/medium/high priority, because often everything becomes a high priority as the project progresses. But when you see a list of all projects, you actually slot it in the list where it’s important…relatively.

Rule #3: Ice box future features 

Whenever someone comes up with an idea for a future version, slot it in the ice box where you can see it for the next version.

Rule #4: Put all communication into one mailing list

Create an archive for agile development team members, which they can access and see the history of past discussions. Everyone needs to be on track as to what’s going on.

Rule #5: Weekly meeting

Each week is seen as a “sprint” of work to be reflected on once a week. Mobile projects are shorter, so this is really important to take a look at the project on a weekly basis. Use this time to accept or reject stories in Tracker. And use this to plan for the next week.

Rule #6: Pair programming

This is a controversial topic, but it has worked for Extreme Labs. Thawar describes it to being similar to rally racing. Two people in one car focused on the same goal. One person is doing the driving and the other person is navigating. With pair programming, one is typing and the other person is looking things up. Difference between pair programming and rally racing is the two parties can switch roles at any moment.

The value of pair programming is it delivers high intensity programming. It’s very hard to screw around on Facebook and Twitter when you’re programming alongside someone else. You get a higher quality product because two people are touching every single line of code. In addition, you don’t get stuck so quickly and hung up one issue. Your partner may know the answer. It’s also a great fast way to train people in an apprentice model. For more on pair programming, watch my interview with Thawar, and read Thawar’s article on the subject in TechCrunch.

Rule #7: Daily cadence

Have a regular schedule that involves the above steps and include working together in one giant war room. They have very intense work from 9am to 6pm. They bring in breakfast for the team, and have “standups” where they talk about general issues, and then platform and project issues. They don’t allow for personal communications on coding machines, but they do have email stations for personal communications, plus a game room to clear your mind. They also don’t let anyone work from home. At 6pm everyone stops working.

Rule #8: Weekly cadence

Ship a build to clients every single week. To make that happen engineers have to verify the build, then internal quality assurance (QA), and product QA. They don’t ship on Fridays, yet on Fridays each pair of engineers gets up in front of the company to demo what they did that week. They also use this time to ask the anchors for each project the following questions regarding the week’s progress. How is your velocity? How are your resources? Is the code quality high? Is tracker up to date?

Rule #9: Project cadence

Here are Extreme Labs’ stages for a project from discovery to completion:

  • Discovery
  • Inception
  • Weekly Sprints
  • Milestones
    • Exec demos
    • Architecture review
    • Static analysis tools
    • Security review
    • Platform retrospective
    • Feature freeze
    • Design QA
    • Release candidate and QA
    • Ship to app store
    • Project retrospective

Mobile begs an agile development process

Thawar admits that mobile development is harder because you can’t do constant development since you’re changing the UI constantly. As a result, mobile could benefit from an agile development process.

Related Links

Comments

  1. BY Oleg Ivanovskya says:

    Sounds reasonable until you get to #7, and parts of #8 …

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>