Agile Methods for mobile app development

February 6th, 2010

2009 was a banner year for WorldLink, a company developing mobile apps for iPhone, J2ME, Android, Windows Mobile, and Blackberry. I am currently leading the WorldLink team of talented software developers. We have launched over 15 apps on approximately 20 app stores and revenue is climbing.

As an agilist, I am always looking for ways to streamline the development process and hit the market window faster – without sacrificing quality. For developing mobile applications, I have noticed the use of 3 new and/or emerging agile techniques:

1. User Design Studio
2. Hyper-prototyping
3. Pair debugging

User Design Studio uses the metaphor of an art studio displaying new art work. People view the art and give feedback – both positive and constructive. When developing the user interface for a mobile application, we often use this technique to generate new ideas and build consensus around the wisdom of the crowd. The User Design Studio technique is described in our white paper “Emerging Agile Techniques” at www.threebeacons.com. Download it for free and see if it might work for you!

As software folks, we are familiar with rapid prototyping. Hyper-prototyping differs from classic rapid prototyping in terms of speed of development, tighter code/test loops, and level of collaboration. For developing mobile apps, and especially mobile app user interfaces, this technique has proven invaluable to our success at WorldLink. I will be explaining it in more detail in an upcoming webinar, so stay tuned!

You have probably heard of pair programming – it is one of the 12 fundamental tenets of Extreme Programming. However, it is probably the least used due to various reasons. But, I do see a strong use of “pair debugging” in mobile app development. When a programmer is developing and testing a critical piece of code and is hitting some impediments, it is often very useful to ask a colleague to help debug the code. Two eyes on the code often results in overcoming the impediment must faster than one set of eyes. I will also be discussing this technique in an upcoming webinar.

Good luck and stay agile!

Michael Hall
CSM, agile evangelist, and software team leader

Posted in agile | No Comments »

Dual-Shore Agile Software Development – Is It Effective?

March 6th, 2009

On Wednesday March 4, I delivered a webinar on the topic “Dual-Shore Agile Software Development – Is It Effective?” The webinar had good attendance and generated some good follow-up questions.

To begin, I stepped through the business case for dual-shore offshoring. Hard data evidence shows you can save up to 20 – 40% in development costs by utilizing an efficient offshore strategy. Then, I introduced Agile Methods and the business case showing a 30 – 40% savings and substantial boost in productivity. Please refer to the Three Beacons white paper “The Business Case for Agile” for the proof.

Then, I posed the question “can these two approaches work together effectively?” Before I answered, I stepped through the challenges associated with Dual-Shore Agile across the following 3 areas: people, information sharing / communication, and project organization. Then I presented the current “best practices” as a form of solution for the challenges. For the “best practices”, I organized the data into preparing for the project, executing the project, and ending the project.

I concluded the webinar presentation by showing some early data that shows there is an additional 10 – 15% bump in savings and productivity when combining Dual-Shore with Agile. In these tough economic times, teams should seriously consider aligning with Dual-Shore and Agile experts.

Three Beacons now has a white paper “Dual-Shore Agile Outsourcing – Challenges and Best Practices” covering all of my research findings. Give it a read!

Posted in agile | No Comments »

Gartner Mobile & Wireless Summit 2009

March 6th, 2009

The Gartner Mobile & Wireless Summit 2009 conference was held February 23 – 25 in Chicago. I attended and went to most of the Mobile Applications tracks. The highlights of the conference for me were:

  • Dr. Andrew Lippman, head of the MIT Media Lab delivered a keynote session. He described “context” and “identity” as core to any communication. There will be a middleware layer above IP and below apps where context and identity are managed. Eventually, there will be one repository of identity that each app references, as opposed to today’s world of each app having the person’s identity. He said that intelligent mobile agents will be used to transmit identity changes to the different apps. Intelligent mobile agents were a hot research topic in the 90s but never really found a good application use. It now appears that Context-Aware Computing is the application that needs this technology.
  • 1-on-1 session with the head of the Gartner Research division Michael King. He gaves lots of good practical advice for developing mobile applications and the market possibilities.

    • Gartner also reminded us that history shows that immediately after a recession, a technology boom follows.

    Posted in agile | No Comments »

    Agile 2009 conference later this year!

    January 29th, 2009

    The Agile 200x Conference is the preeminent gathering of Agile thought leaders. I’ve been to most of the previous ones, and was always blown away with the level of learning available. This year’s version, Agile 2009, looks to be another huge success with the main theme “Making Agile Real”. Once again, it looks like a large number of sessions, tutorials, workshops, and talks.

    If you are new to Agile Methods or an experienced agilist looking for additional improvement, this conference is for you. The conference is August 24 – 28 in Chicago at the Hyatt Regency.

    If you are going, drop me a line at mike@threebeacons.com and we’ll meet up for a coffee or hot tea and discuss the Cubs chances this year!

    Tags: , , ,
    Posted in agile | No Comments »

    Agile Versus Ad-Hoc V3

    December 31st, 2008

    I was interviewing a junior candidate recently and mentioned to him that we use agile methods to develop our software. He seemed interested and asked “How does that work? I mean, how do you develop software without doing up front design and requirements?”

     

    My initial reaction was stunned silence. Then I recovered. I realized he was young in his career and was relying on what he learned at his university – do the requirements, then do the analysis, then do the design, then do the coding, then do the testing, then do the deployment, then do the maintenance. Classic waterfall.

     

    In his mind, “agile” meant skipping all of the important planning steps and immediately jumping into the coding. Yikes.

     

    I used the opportunity to mentor and teach the young man that “agile” is actually the most disciplined software development approach around. Anyone who tells you otherwise is doing a disservice to software development. The idea that “agile” is the same as “ad hoc” is just simply incorrect. In many ways, “agile” is the opposite of “ad-hoc”. Agile is not “hurley gurley” like ad-hoc. You can be proud if your team is agile. If your team is ad-hoc, you should be motivated to find help.

     

    It is true that the most important aspect of Agile is the fast development of working code. But how do you get to working code faster? You do bite-size chunks of requirements gathering, analysis, design, and test – in support of developing code. You prioritize ruthlessly. You develop user stories on index cards to capture requirements. You use these cards as reminders to discuss them further. The PM or development team writes use cases to clarify and/or regurgitate their understanding of the requirement. Preliminary object models are pulled from the use cases and documented. Key Design Ideas are captured for future reference. Test case automation is established in order to create a repeatable verification. Continuous integration of the build is set up. Test-driven development tools are installed to drive quality upwards. The team meets daily in a brief stand-up to insure synchronization. The team does a detailed plan for the upcoming iteration. The team demonstrates their working code each month.

     

    Does that sound like “Oh, we just code?”  No way.

     

    Does it sound like “Too much”? No, it is focusing your time and talents on the things that really matter – working code with high quality – and ignoring or de-emphasizing everything else. I like to call it “ruthless focus”.

     

    The candidate understood, so I’m still considering hiring him.

    Tags: , , , , , ,
    Posted in agile | No Comments »

    Your PM Team Will Love User Stories!

    October 3rd, 2008

    Requirements engineering is tough. It takes a very talented product/project manager (PM) to get it right. A high-performing effective PM team can give you a distinct advantage over the competition. Not everyone can do this job effectively. But, unfortunately we make it even tougher on them. Yes, we.

     

    There is a better way if:

    • You require PMs to develop a detailed requirements specification up front

    • You support your software teams when they say they cannot start without detailed requirements

    • You don’t like it when requirements change

     

    While certain life-critical systems require this kind of up-front rigor and expense, most software systems do not. Most software systems development can assume that requirements will become clearer the deeper into the lifecycle you get. It is a reasonable risk to trade off in order to get started.

     

    Agile Methods do not require a frozen list of requirements locked in to start the project. Agile says

    “Start with what you know”

    “Clarify as you go”

    It even rhymes! I bet there is a poem in there somewhere.

     

    An excellent method for gathering requirements early in the project is the User Story. User Stories are low cost and low fidelity. That means they can be developed in a short time frame and changes are handled easily. User stories are written on index cards. Usually 4 x 6 is better than 3 x 5 because of the extra real estate.

     

    To prove my point about low fidelity:

    • What if you decide to delete a user story? Action: discard the card into the nearest trash can.

    • What if you decide to modify a user story? Erase and write the modified text.

    • What if you need a new user story? Grab a card and write it (in pencil).

    • How do you monitor progress of user story development? Put the cards on a board with columns for “Not Started”, “In Work”, and “Done”.

     

    User stories have a simple requirement written on the front of the card in the form of role, function, and business value. High-level test cases are written on the back in the form of actions and expected results.

     

    Your PMs will especially love this about user stories – often times the initial set of user stories is derived from a user story workshop. The PM invites key individuals such as the customer, customer proxy, software developers, testers, release builders, etc. The PM brings lots of index cards and pencils with erasers. The PM presents the vision of the project followed by a few of the obvious user stories. These are discussed and modified as consensus develops. The rest of the team then begins brainstorming. Additional user stories emerge and are captured on the index cards. The customer or proxy can guide explicit guidance on the relevance of a user story.

     

    The “wisdom of the crowds” comes into play strongly at the user story workshop. It is highly collaborative and consensus rules. Disagreements will arise, but treat them as healthy discussion opportunities. The customer or PM can make the final call.

     

    Teamwork psychology also comes into play during the user story workshop. A team member that suggests a new user story is handed a card and a pencil. They get to write the user story and read it back to the team for feedback. This makes them feel like a valuable contributing member to the team. If you have quiet lead-by-example folks on your team, this is an excellent way to help them improve their communication skills.

     

    At the conclusion of the user story workshop, the PM is armed with an excellent preliminary list of requirements – in about ½ day. Software development can begin in a “start with what you know” approach. Yes, I said it – the same day the project started. Is there any other requirements engineering technique that can make the same claim? I doubt it.

     

    Compare this approach to the following assignment: your job as PM is to query the customer, do some market analysis, and write a comprehensive requirements spec due in 2 months in order to kick off this critical project. No excuses. You better not be late. Good luck.

     

    Do your PM and Software teams a big favor. Shift over to User Stories.

     

    I’m not kidding. Your PMs will love it!

     

    Tags: , , ,
    Posted in agile | No Comments »

    Agile 2008 Conference musings

    August 8th, 2008

    1600 attendees. This conference is huge. Every scheduled time has over 50 sessions to choose from.

     

    Keynote speaker James Surowiecki talked about his new book The Wisdom of Crowds and how it applies to agile software development. It was an excellent keynote packed with many examples of how the consensus of crowds beats singular expertise every time. From a development perspective, I think we should use the wisdom of crowds in the following areas:

     

    • Schedule estimates

    • User Interface designs

    • User story requirements

    • User story points estimates

    • Release planning

    • Design discussions

     

    Best session: User Interface Design Studio, by Jeff White and Jim Ungar

    This session described an agile technique for collaboratively developing user interfaces. It starts with the PM describing a vision and then everyone develops their own user interface. Each user interface is presented for feedback from the audience. The best ideas and ideas to avoid are tracked. Then, the team does a final design pulling from all of the best ideas. Wisdom of the crowds at its finest!

     

    Lots of sessions on User Stories and Estimating User Stories.

    “It’s better to be roughly right than precisely wrong.” – John Maynard Keynes

    Estimate size, then derive duration. The velocity of the project team will become apparent after 2 or 3 iterations.

     

    10 Ways to Screw UP Despite Scrum and XP, by Henrik Kniberg

    1. Believing the hype
    2. Not having a good definition of “done”
    3. Not knowing your team’s velocity
    4. De-emphasizing the retrospectives
    5. Poor management of team commitment
    6. Allowing technical debt
    7. Ego-centric designs
    8. Not keeping the product backlog updated
    9. Merge-o-phobia
    10. Not keeping the iteration backlog visible

     

    Ole’s 8 Steps for Agile Mentors, by Ole Jepsen

    1. Agile training
    2. Use Case / User Story boot camp
    3. Release planning game
    4. Iteration planning game
    5. Show up and ask “how is it going?”
    6. Check on the demo
    7. Demo and reflection
    8. Evaluate demo and build new plan

     

    User Stories and Use Cases? Sure, It Even Makes Sense, by Jamie Allsop

    This was a quick overview of the differences between user stories and use cases and when to use either or both. I thought several things were missing in the presentation, so I’ll try to write a white paper to share my thoughts and experiences.

     

    Many, many other sessions. Overall an excellent conference, but with so much to choose from you could not help from thinking what you were missing – especially when you attended a weak session.

    Tags: ,
    Posted in agile | No Comments »

    Agile Versus Ad-Hoc V2

    August 1st, 2008

    I was having lunch with a friend and she said her company was doing “agile”. I asked her to explain. She shrugged her shoulders and said “We don’t write documents.”

     

    Ouch. Oh, don’t get me started.

     

    It was a nice 2-hour lunch because of the ensuing conversation between friends.

     

    We’ve all grown up in a time where our assignment was to write a glorious thick document (detail design document, requirements spec, etc.), that was never read. I’m as guilty as the rest. I once assigned a senior engineer the task of developing a detailed design for the user interface of a new product. He had built a wonderful 2-inch thick detailed design describing in detail the classes and interactions he would be using. The review was scheduled for 3 hours. It lasted 10 minutes. Why? No one had read it. Not even me. Ouch. The only feedback received was that on page 3 there was a long rambling sentence and wouldn’t it be better if it was split into 2 sentences. I’m not kidding. Tom, if you are still out there, I apologize. That 2 months could have been used writing code.

     

    Ever since that experience I have challenged myself and my teams to develop minimal documentation, but documentation that really matters. One example is the Key Design Idea (KDI). KDIs are a high-level conceptual design, typically described pictorially with labels and a few sentences. Running a project usually results in 3 or 4 KDIs developed to capture the salient design aspects. A KDI can be developed usually within 1 day.

     

    Agile Methods certainly de-emphasize the writing of documents. As a matter of fact, the original Agile Manifesto states: “We value working software over comprehensive documentation”. The great thing about agile is that you don’t write documents for documentation or process sake.

     

    Agile helps you to think of documents as a result of an agile activity (as opposed to an assigned deliverable). For example, as you are writing code your design firms up. There is an important new aspect of your design emerging. You need to capture it in a KDI. Another example is holding a User Story workshop. Participants collaboratively brainstorm the requirements. As requirements are identified, they are written on index cards. The result of the workshop is a collection of user story cards – a “minimal document” of the agile activity. Yes, the stack of cards is the document! Another wonderful example of a document is a drawing on a whiteboard showing an architectural layering of your system. Take a digital photo of the drawing and put it on the server in the Designs folder. I’m not kidding – it is a document.

     

    Examples of documents in an agile world include: user story cards, use cases, KDIs, product backlogs, iteration backlogs, overall release plan, reflection meeting findings, wiki pages, etc. Even the Kanban board with attached story cards under columns for “done”, “in work”, and “not started” is an example of an agile document!

     

    Does that sound like “We don’t write documents?”  No way.

     

    Agile puts it in a different perspective – documents are minimal and meaningful – as they should be. They are a natural output of the agile practices. They are supportive in nature to writing code.

     

    Compare this to the old-fashioned ways of developing software where the deliverable assignment was a document. Do you see the difference?

     

    I still paid for lunch, but she will pay next time!

    Tags: , , ,
    Posted in agile | No Comments »

    Agile Versus Ad-Hoc V1

    February 13th, 2008

    One of my colleagues recently shared his vision of agile:

    • Siloed development
    • No code reviews
    • No documents
    • No iterations
    • No coding standards
    • No retrospectives
    • No team-based design
    • No written requirements
    • No planning – just do it!
    • Collection of subject-matter experts, but not really a team

    Wow. I’m not sure exactly what that equates to, but I think Robert Martin would call it “crap”.

    Perhaps my colleague prefers an ad-hoc development environment where reliance on heroes (of which he is one) exists. It is sad that many (dare I say most?) software development teams are plagued with this approach.

    Here is my contrary vision of agile as a practitioner with 8 years of experience and as a Certified Scrum Master:

    • Team-based development
    • Buddy code reviews
    • Minimal but meaningful documents
    • Monthly iterations (or shorter)
    • Coding standards documented and enforced
    • Retrospectives held after each iteration, feedback loop for improvement
    • Team-based design consensus
    • Written requirements in the form of User Stories
    • Detailed planning for the next iteration, overall high-level planning for the project
    • Subject-matter experts where required, but team is highly collaborative and helpful

    Do you see the difference? Which will be successful? Which is better for the company bottom line?

    Tags: , , , ,
    Posted in agile | No Comments »