Join leaders from MIT and Vizio for a Remote IoT Development Virtual Summit.

Subscribe to our blog to get the latest articles straight to your inbox.

This is part of our How We Work series of blog posts. Today, we’re talking about how we use Iterative Development to break down large project into smaller chunks.

The Key Questions

The questions we'll answer here are:

  • What is your development workflow and cadence?
  • What is the format for regular meetings?
  • What tools will you use to manage this project?
  • How available do I need to be during the project?

What is Your Development Workflow and Cadence?

We can iterate and launch over and over (and over) again. Sometimes, it's necessary: business processes change or new features come into play. But we're well aware that software development can go on forever — and it can be hard to know when to stop. So we consider every launch a realistic stopping point, which means we deliver a product that's ready to hit the market and thrive.

While a fully functional minimal marketable product (MMP) might require multiple releases to be "feature complete," building in releases gives us logical stopping points to re-evaluate our progress and optimize our strategy to fit current business needs.

How Available do I Need to be During the Project?

While we are readily available to collaborate during business hours, our clients can expect regular touch points with our team:

  • Planning: 90 min. once a month, or when the backlog gets low
  • Iteration Planning: 40 min. once a week, during iteration planning
  • Demo/Feedback: 20 min. once a week, before iteration planning or at the end of the iteration
  • Standups: 5 min. once a day
  • Retrospective: 20 min. once a week, after demo but before iteration planning
  • Daily or as needed strategy session with your Engineering Team, PM's and Stakeholders

In order for your project to go smoothly and meet your expectations, we need a designated product owner from your team to attend every scheduled planning meeting. You can expect planning meetings to occur each Monday and last less than an hour. If we are planning for an upcoming release (a month of work), the meeting may go longer, but we try to keep them around 40 minutes. You are also welcome to join any of the daily standups, but they are not mandatory. 

What is the Format for Regular Meetings?

  • Demo: We show completed features or work-in-progress features from the previous week — no matter how rough it is.
  • Feedback: You share responses and questions from the demos.
  • Review Project Health Metrics: Velocity, volatility, red flags. The velocity of the previous iteration should dictate what the team will complete for the current iteration.
  • Retrospective: A template, which you can copy into the Project's Drive Folder.
  • Business Update: A discussion of any business changes that impact prioritization of this iteration's work.
  • Groom Pivotal Board: Together, we select cards to commit to delivering this iteration.
  • Plan: Engineers breakout and plan implementation of cards.
  • Budget and Scope Update: We review the remaining budget, hours spent and overall progress. Then, we make decisions about scope adjustments.

Expecting the Unexpected

In case you haven't noticed, we're planners. But we're also realists: we know that we can't anticipate everything. Inevitably, when you're dealing with software development, items will arise during the project that no one can foresee.

Often, this happens when business processes change or new features come into play. Whatever the cause, it's normal. In fact, it's a good thing: it means we're evolving and improving, asking different questions and finding the right answers, and coming up with bigger and better ideas.

Very's change protocol starts with creating new Pivotal cards in the "Drop Lane," and our engineers document scope, requirements and implementation time. Then, you decide whether to approve the change.

Our weekly iteration planning meeting is another opportunity to make necessary shifts and course corrections. After we demo working software, we hold a brief retrospective that focuses on improving the process and prioritizing tasks for the upcoming iteration. Always, we work on the cards in the order you specify — and when that order changes, we're as flexible as we can possibly be. Our goal is to provide the sport and insight you need to optimize your time and investment, and to maximize the return.

Our Development Process

Agile + Lean Methodologies

Lean development is all about validating assumptions through experimentation and market data. The goal is to increase efficiency while reducing the amount of waste we create during the process. Lean development was inspired by, and draws directly from, lean manufacturing.

Take Kanban, for instance. Popularized by Toyota, Kanban is a lean manufacturing process that uses visual cards as a signaling system. (In Japanese, the word "kan" means "visual," and "ban" means "card.") The cards trigger an action to supply the process with its needs, either from an external supplier or from a warehouse. Kanban is structured as a "Pull System," where long and short cards move through the process based on downstream demand.

How we work agile learn Methodologies

Each queue is optimized to perform its function and the entire workflow is managed tightly by using "Work In Progress" limits, preventing more work from being in process than the system can reasonably deliver. This system has clear and powerful applications far beyond manufacturing, which is why Kanban is now a widely followed Agile software development methodology.

Extreme Programming

There are many Agile methodologies, but Extreme Programming (XP) produces the most customer value with the highest quality output.

Agile + Lean Methodologies

XP is a disciplined approach to delivering high-quality software, quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing and planning, and close teamwork. Software is delivered at very frequent intervals — typically every one to three weeks. Ultimately, XP creates flexibility for changing business and product needs. It provides insights into the cost and time to build out features and deploy them.

At Very, this is our project management methodology. It's how we build things, regardless of the language or framework we're using. XP is the way we work.

Tools We'll Use Together

  • Github: Shared, collaborative management and version control for one of your most important assets — your application's code.
  • Google Drive: Our primary repository for all project related documentation, from requirements to contracts and proposals. You've been shared on the root project folder and can collaborate on any documents in your folder with us in real time.
  • Slack: This is how we communicate asynchronously as a company. It's much more efficient than email, has native mobile clients and allows us to link together activity from other third-party tools, like Pivotal and Google Drive. You should have received an invitation to complete the sign-up process.
  • Zoom: We use Zoom to do voice/video calls. It supports large teams concurrently and provides quick and easy options for face-to-face collaboration.
  • Pivotal Tracker: A simple task manager and the backbone of our workflow. All work that needs to be performed is represented on a Pivotal Tracker Story. Stories can have task lists, attachments, and conversation threads. They are grouped and organized to fit the evolution of your individual product.