Let me start with an admission.

We’re drinking the agile kool-aid, and we’re kind of okay with it.

If you don’t know much about the roles and responsibilities of an agile team, and you like videos more than you like reading words…

like these words, on this screen…

I recommend that you check out the video below. It’s one of the quickest and perfectly detailed summaries of the agile process I’ve found that won’t make your eyes bleed.

A lot of what you see here is the process we strive to perfect in our daily delivery of value to our clients’ products.

Why Agile?

No matter what type of project it is, everything we do requires collaborative innovation. Nobody can work in a silo and produce one of the apps that we create.

No matter what type of project it is, everything we do requires collaborative innovation. Nobody can work in a silo and produce one of the apps that we create.

We’ve tried a lot of digital project management methodologies. Everything from a buck-the-system free-for-all to a red-tape-everywhere, document, review, get three approvals on everything approach. The products always end up in a good place, but the path getting there is very, very different.

In the free-for-all, a lot of great ideas surface. But there’s also a major lack of the right kind of communication. There’s a ton of waste and rework in this approach. Not something a client-agency relationship generally benefits from.

In the stodgy checks-and-balances approach, communication is constant. There are pre-meetings and post-meetings for every meeting. Everyone has some semblance of confidence that everyone that could possibly need to weigh in on the project knows what’s going on, hope that somebody is making the right decisions, and the reassurance that, when things go wrong, there are plenty of other people to point the finger at.

As you can imagine, with this tyrannical approach to product creation, products ship at a positively glacial pace. That’s not a great situation for users or for the business trying to bring value to their users and their bottom line.

Now, we try not to be particularly religious about process. As a company, we’re more principles-oriented than we are process-oriented. That said, we’ve found that the best balance of productivity, communication, user benefit, and business value is had with a process that is roughly the “vanilla” agile process.

Our Agile PM

Every project we work on is assigned an “agile team.” We generally don’t allow our agile teams to get bigger than 6–8 people, not counting contributors from our client’s roster. We find that we work best in small, tactical groups represented by a variety of unique skill sets with limited overlap.

Every agile team has a Product Owner who we refer to as the Agile Project Manager (Agile PM). We use the term “PM” instead of straight-up “Product Owner” to be a little more self-descriptive to the outside world — the others who may not be dreaming in agile-speak.

The Agile PM is responsible for being our client’s point person inside their agile team. The Agile PM works with the client to define the users, business goals, and use cases for the product we are collaboratively building.

On the agile team, it is the Agile PM’s role to translate all of these use cases into prioritized specifications for one or several two-week deliverable periods, called “sprints.”

The rest of the agile team is comprised of just the right number of individuals, representing just the right kind of skill sets needed to fulfill the requirements of each sprint. For any particular skill set, we aim to remain consistent with the team member responsible for that portion of our deliverables throughout an entire project. But every skill set is not needed all the time. So the composition of the agile team on a project can and does change over the course of a project.

The Agile PM, however, is a constant.

One of the benefits of a “revolving door” approach to team composition is one of the great advantages clients can gain from working with a consultative company like ours.

When the alternative to collaborating with a company like Camber Creative is building a product team internally, the value proposition of deploying our specialized team members only when and how much you need them versus attracting and employing a full-time team can be extremely compelling.

When the alternative to collaborating with a company like Camber Creative is building a product team internally, the value proposition of deploying our specialized team members only when and how much you need them versus attracting and employing a full-time team can be extremely compelling.

Still with me?

Buckle down, we’re getting into the process now. :)

Our Workflow

We believe in delivering incremental value constantly to the users of the apps that we create. We think our agile workflow is the best way to do that. As such, we highly encourage our clients to adopt a continuous release cycle that aligns with our sprint schedule.

You can think of our development workflow as atomic in nature. Many small, independent completed components come together to form something progressively more complex and more useful over time.

1. User Stories

The fundamental components of every product that we create are referred to as “User Stories.” For example, if one of the requirements of your app is that users need to be able to create a new account or log in using their existing Facebook account, we might write a user story like,

As a user, I can create and log in with an account using my Facebook login, so that I can quickly on-board into the app without having to create a new username and password.

Every user story is going to be structured the same way. It’s always:

• one sentence,
• describing one small (atomic) piece of functionality,
• told from the perspective of the user as if they were in front of your app right now,
• containing not only the feature, but a brief statement on the benefit this feature gives to me as that user.

That last part is easy to phone home, but we feel strongly about including it because it’s fundamentally rooted in the “why” of that feature.

The “I can” part of a user story answers the “what is this feature” part, but the “so that” part answers the incredibly salient “why should this feature exist” question by framing the feature around the specific value the feature’s implementation would bring to the user. Putting the user first, even when defining a feature, is a good mentality in my view.

Putting the user first, even when defining a feature, is a good mentality in my view.

User stories are not, and should not be, comprehensively defined up-front. Your product vision, user needs, and product-market-fit are going to become better defined over time and throughout your continuous release cycle as you learn more and validate your ideas. Too much planning, after all, can be just as detrimental to your product, users, and business as too little.

2. Planning Poker

Yeah, it’s a dumb name for a smart “game” we play. Before diving into the implementation of your user stories, and importantly before making a huge economic commitment to us or any other app design & development firm, it’s important to understand the level of effort for what we are getting ourselves into.

The concept of Planning Poker involves sharing the completed list of user stories with a group closely resembling the variety of team members you will see on your agile team when implementing the project.

During Planning Poker, the team estimates the level of effort for each user story relative to all other stories. This is done with abstracted, relative estimation units. Some people use t-shirt sizes like S, M, L, XL — we use “story points.”

The story points scale we use is a modified Fibonacci sequence comprised of the following values: 0.5, 1, 2, 3, 5, 8, and so on.

We start with mutually identifying a user story that is relatively simple and can act as a “base unit of effort” to compare other stories against. That story is assigned a story point value of 1.

From there, we talk through the rest of the list of user stories, and assign a story point value to each one, rating it based on how complex it is relative to the 1-point story we started with. The logic being that a 2-point story would be roughly twice as complex as a 1 point story, and so on.

It’s called poker because each participant presents their story point estimate on a physical card at the same time. This process often reveals really great information about how the product can be built because one person sees hidden complexities that the other doesn’t or another person has done a very similar implementation in the past and knows that there is a faster and better way to do it.

We abstract dollar and timeline estimates from the story point estimates we generate using statistical analysis. Our fancy-pants spreadsheet takes original estimates as story point values and converts them into an estimate range for both budget and timeline with a 95% confidence interval, as well as one “best guess” value somewhere in between the low estimate and the high estimate.

Development estimates suck. But we’ve gotten pretty good at them. We even built a free app estimation tool on our website. It’s not perfect, but we think it helps create a good starting point for a conversation about a new app project. If you have an app project in mind, is suggest you give it a try!

Development estimates suck. But we’ve gotten pretty good at them.

‍

3. Sprint Planning

Just like the preparation of user stories and conducting planning poker, sprint planning is a cyclical process. All three of these things happen on an ongoing basis throughout the development of your product.

As I mentioned before, a “sprint” is a two-week period of time with a defined scope for user stories to be completely functional inside your app by the conclusion of those two weeks.

The rules are that the sprint objectives must be clear and manageable, the responsibilities among the agile team for these objectives are clearly understood, and you aren’t allowed to change the active sprint while it’s in motion. It’s hard enough to hit a static target, but it’s much harder, and much less motivating, to hit one that’s moving.

It’s hard enough to hit a static target, but it’s much harder, and much less motivating, to hit one that’s moving.

‍

The sprint planning process is where we rank the priority of user stories that have been prepared and estimated and organize them into an actionable plan for the upcoming sprint(s). Some of these priority decisions are a matter of practicality (like when A has to be done before B can even possibly exist), but it’s also a matter of what’s currently the priority for you and your users.

This is yet another benefit of the agile approach. You can adapt and pivot extremely quickly as your needs and priorities change.

4. Continuous Integration, Iteration & Validation

We always want to put the latest and greatest product in yours and your users’ hands as fast as possible. We think showing is better than telling in our line of work.

We think showing is better than telling in our line of work.

It’s in this spirit of transparency that we use technology that enables us to share our work-in-progress with you on a continuous basis, and in turn for you to decide the frequency with which we push those updates out to a wider audience to include your early testers or even your live app users.

For example, on all of our mobile projects, we use a platform called BuddyBuild that alerts you with an email every time we deploy a new feature. That email contains a new downloadable app build that you can install and run on your phone in just a couple of taps.

Sometimes, you might even receive multiple new build alerts in the same day, each with a note about what’s new inside that build. You get to see the app evolve right in front of your eyes. There’s no question about what’s done and what’s still to do.

Our goal at the conclusion of each sprint is to have functionally completed all of the user stories that were planned for that sprint, meaning each user story, like the one I mentioned above, can be read as a true statement.

Signing off for now…

There’s more to tell, but I think these basics give you a really solid starting look into our operation, and how we think.

We’ll continue to post more content as we strive for continuous improvement in our own process.