Some notes on Agile Development

Agile development is a Cult to some, a Fad or just plain old weird to others. I’m a fan of this type of development. I’ve seen teams do great work by adopting Agile and a framework to execute it. Agile isn’t magic bullet however. Some Agile projects fail. I do find it the best way to iterate and communicate, so it really works for me personally. I’d like to go over the Agile Manifesto and add in my own notes.

But first, some definitions for those new to Agile and to make sure I’m clear on any of my own jargon.

That’s a good enough intro to get us running. On to the Manifesto itself. It reads:

The stuff on the right is important, but it’s not as important as the stuff on the left. Hence my use of the Greater Than symbol. That last bit about responding to change applies to the Agile Development process itself. In Agile, the team is supposed to evaluate the process they’re using and adapt to change. Teams that don’t change have a greater risk of failed projects. Change can be hard, but the process requires you to do so, which can only lead to growth, imho.

The 12 principles of the Agile Manifesto:

  1. The Highest Priority is to satisfy the customer through early and continuous delivery of valuable software. Iterate, iterate and iterate some more. Agile wants transparency with the client at all times. A working version of the software, even without all the features is the thing to evaluate at a given time. This helps you learn, collaborate and pivot.

  2. Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage. The time you know the least about what you’re building is at the beginning (planning). If you close off the opportunity to change, you can wind up building the wrong thing, or the thing that no one wants to use. But you can’t run around changing everything everyday, madness that way lies. So you generally protect the Sprint commitments as much as possible, and plan on evaluating and changing priorities for next Sprint.

  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Make something quickly, evaluate it, adjust. Pivoting is key in software development, short cycles help you know what you don’t know.

  4. Business people and developers must work together daily throughout the project. The Product Owner fills this role most often. That person must know business and development well. Their knowledge doesn’t have to be deep on either end, they have to be great in that gray area in the middle. Although Scrum Masters and Developers should be versed in this too, or at least know enough about the customers business to be able to anticipate challenges, and generate ideas.

  5. Build Projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. On a personal level this one rings so true to me. It’s not about just getting out of the way”, although sometimes that’s the best thing to do. It’s about setting clear goals and a cadence and supporting the developers. That can be rendered in a million different ways. This is the work I enjoy most.

  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working with remote team members is wonderful. It allows a company to not be constrained geographically when looking for and keeping talent. That said, it’s a challenge to stay in touch if everyone isn’t in the same space. Talk to each other face-to-face if you can. Video chat if you can’t. Have a Slack/HipChat/whatever too. Talk to each other.

  7. Working software is the primary measure of progress. This sounds so simple, and it is. How’s the project doing? Look at the latest build. We’re good at building all kinds of metrics and data-driven evaluations. Those can be great supporting metrics. The latest build is the best. It informs you of what you know, and what you don’t know, at that point in time.

  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. A lot of people new to Agile don’t really grok this. There are processes to measure the development teams Velocity. Which is simply how much the team can get done in a time period. Velocity is best measured in a system that takes into account Complexity, not Hours. This system lets you know how much you’ll be able to get done in the Sprint. And when things change, as they always do, you’ll be able to adjust.
    There’s so much to this, as it’s a weird metric for some people. The short story is to find a task that everyone agrees is not complex’. Use that as a base-line to measure the others tasks against. Categorize everything in a complexity system comprised of Story Points, or T-shirt sizes, whichever works for your team. Then measure how many of these points you can get done in a Sprint. That’s your Velocity. You’ll need several Sprints and some discussions to understand the average and to make sure your categorization is correct. It’s so worth it. Once you have this information, you can tell each other, the client or anyone else what you’ll be able to do in a Sprint right from quick discussion about the Backlog.

  9. Continuous attention to technical excellence and good design enhances agility. Humans want to do the best job they can. It’s just in our nature. After all, We are here to make a dent in the universe”. A Scrum Master who builds the right information, space and time into the team lets everyone trust each other. A team that trusts each other will do the best work they can, and support each other while doing so.

  10. Simplicity — the art of maximizing the amount of work not done — is essential. The best way to simplify is to reduce. Cut features. A dropped feature is better than a broken or incomplete one. A Scrum Master can look to reduce the amount of waste as a way to simplify. Importance should be measured by the frequency the user needs to do something, how big things are on the page, etc. Cut it down to the essential. Build that. Learn from it. Expand it. Deliver working things, and iterate.

  11. The best architectures, requirements and designs emerge from self-organizing teams. The team wants to be awesome. They’ll self organize to maximize each other. Management can guide this, and help the team figure out who’s best at what types of work. But Management should resist dictating the who’s doing what. Let each member of the team grow, when appropriate. People want to be awesome, guide them and let them.

  12. At regular intervals, the team reflects on how to become more effective, the tunes and adjusts its behavior accordingly. There are a couple of ways to evaluate the teams effectiveness. First is on a one-on-one basis, of course. The Scrum Master should be meeting regularly with each team member individually to discuss their progress, goals, growth and interests.
    The Sprint Retrospective is the place to collectively discuss the effectiveness of the team. When a team first comes together, these meetings can be too quiet. If there isn’t enough trust yet, no one will want to speak up. As the Scrum Master, start with yourself. You’re a part of the team after all. As a Scrum Master, I like being a Pig. Tell the team this is what you think you can do better or differently. Start there. Build the trust.

Agile works for me as I’m a fan of simplicity, Boyd’s Law of Iteration and working with teams. The team builds great momentum from constantly shipping software. Yes it’s frequent shipping of small pieces, but those pieces add up quickly and great trust and collaboration is built.

Posted on 11/19/2015

Where the Light Gathers is a blog by Chad Moore.

I write about doing less with technology, parenthood, working with creative and technical people, improv comedy, writing fiction, and woodworking.

Email me, check out my Micro Blog where I post photos and what I'm thinking, reading, or watching. Or read another post:

January 2019  1 post


November 2018  4 posts

Change  ·  Calls  ·  Using a minimal iPhone  ·  Unoverwhelmed

October 2018  1 post

My new old computer

September 2018  2 posts

Improv101  ·  A Quiet Place

August 2018  2 posts

The Other Direction  ·  Blotmentions

July 2018  3 posts

Side Hustle Sprint  ·  Beep  ·  Minimal design

June 2018  1 post

Setting up and

April 2018  2 posts

blotter  ·  Time

March 2018  1 post

Minimal Digital

December 2017  1 post

Side Hustle

November 2017  1 post

The Art of 3D Modeling at Digital Portsmouth

October 2017  1 post


September 2017  1 post

Leadership for Animators (and other creative people too)

August 2017  1 post


July 2017  4 posts

Drafts and Actions  ·  First things first  ·  100 years  ·  Lower than Erlich

March 2017  4 posts

I am not a minimalist  ·  Sips  ·  Carrd  ·  conservation

February 2017  7 posts

WTF per paragraph  ·  chimera  ·  Text Expansion is built into iOS  ·  Blot, aText & nvAlt  ·  Collusion  ·  Tsundoku  ·  A simpler way

January 2017  1 post


December 2016  2 posts

Don't compare your backstage to their onstage  ·  Ideas are cheap

September 2016  3 posts

Kid A, Owls, and perfect pens.  ·  I am uncomfortable, which is good.  ·  The perfect pen

August 2016  2 posts

Premortem  ·  Every 6 weeks

July 2016  3 posts

Mini-disconnects  ·  Get to know a furnace.  ·  Just the Facts

June 2016  4 posts

Dude, where’s my car?  ·  The Doodle  ·  Crazy  ·  Bones

February 2016  4 posts

Broken Records  ·  Little white numbers in little red circles  ·  Squirrel  ·  Right Now

January 2016  2 posts

I loved arguing with my son about doing his homework Never Alone

December 2015  1 post

Mr. Oldman stands up and expands

November 2015  3 posts

Some notes on Agile Development  ·  Single Tasking and Spotlight  ·  Sacrifices

October 2015  1 post

My Leaf blower doesn’t have bluetooth

June 2015  1 post

#Digital Portsmouth, The Art of Video Games

April 2015  2 posts

A call from out of the blue Ask

September 2014  1 post


May 2014  1 post

Nerd Alert

August 2013  1 post

UX for Technical Artists

February 2013  1 post

Cliques and Tribes

January 2013  2 posts

Pay it Forward Trust

May 2012  1 post

Four Distractions

October 2011  1 post

The three things we need at work