Agile Web Development: Our Approach to Project Management

information on website project management

There are many methodologies that relate to project management for websites, but the most widely used methods are Agile, Scrum, Waterfall, and Kanban.  

At Bear Group we have used all of these frameworks in our project management of websites, in some form, depending on the type of project as well as the client’s goal(s), timeline, and budget. While there are essential elements of these project management processes that should always be adhered to, we also recognize that every project and client is unique and it’s vital that there’s a level of flexibility in how a project is managed.

While we encourage our team members to have structured processes, we also encourage them to think outside the box — not only in terms of coding — but also in how we run projects. That's why one of the key principles in the Agile Manifesto is “Individuals and interactions over processes and tools."

Our Run State program uses elements of Lean and Scrum, our internal Marketing team and Documentation Council use Kanban, and our Project team uses Agile and sometimes Waterfall depending on the phase of the project (e.g. for full redesigns with heavy content restructuring, we treat the initial phases of the project in a “Waterfall” manner).

In this post, we’ll focus on how our project team employs a hybrid Agile approach where allowing elements of flexibility in a solid build plan is encouraged.

Agile Development Approach

Our “hybrid” Agile approach to website project management stems from the fact that we care more about being flexible and reasonable when working with our diverse client base than sticking 100% to an intractable framework. Creativity — when paired with practicality — is strongly encouraged at Bear Group in every department.

Scope/Build Plan

The client’s business needs and requirements should always be in the foreground throughout the project lifecycle. Most of the time, our clients have established the goals of the project, and we have also consulted and advised in this realm, particularly in product development.

Once goals are identified and collectively understood, we engage in a scoping phase that includes research and discovery, stakeholder interviews, and prototyping if necessary. The output of this phase is a solid, structured scope document that provides a build plan for how we can achieve the client’s goals and objectives.

We also include a milestone calendar that outlines the sprints, when clients need to be engaged (for content audits/integration, training, UAT), and estimated delivery dates.

At the outset, we create a plan with a Waterfall approach in mind: a more linear process with a defined timeline, itemized constraints, and a set of requirements. However, the reality (particularly for complex, highly customized builds) is that requirement shifts and iterations are inevitable; this is why we embrace an Agile approach during the development phase of projects.

Want to Learn More About Agile Development?

Download the Bear Group whitepaper about using the agile approach to learn more and see if it's the right framework for your team.

Download the Whitepaper



If scope adjustments arise that are deemed high-priority by the clients, we will always evaluate and then provide our recommendations on where we think the feature should fit into the build. Here are some questions/considerations we ask ourselves when compiling estimates and constructing our recommendations:

  1. Is the new feature aligned with and essential to the original project goal(s)?

  2. Does it have a significant impact on the project budget/schedule?

  3. Is it creating technical debt?

  4. Can this feature be addressed in a post-deploy sprint/iteration?

In addition to providing our recommendations, we also ask the following questions to clients before implementing new scope:

  • Is this an essential feature or a nice-to-have? Is it in line with — and essential to fulfilling — the original project goal(s)?

  • What priority does this new adjustment have in comparison to previously greenlit features? Can any of those approved features be de-prioritized and potentially road mapped out post-deploy?

  • Will it be essential to–or expedite the development of — other, already scoped elements? 

  • Is there collective buy-in for this feature within the client’s team? 

  • Does this have any impact (negative or positive) on other individuals or departments?

  • Will this new feature require substantial training or process shifts and does the internal team have the capacity to do this within the pre-launch timeframe?

  • Are the budget and timeline adjustments acceptable? Or is it possible to roadmap out this new feature for a post-launch phase?

In sum, the key is to gather all the new requirements, evaluate and provide clear options, outline our recommendations, and step clients through the pros and cons in great detail. From there, the client will have the full scope of potential project impact and can make an informed and assured decision.

“Innovation is the outcome of a habit, not a random act.” – Sukant Ratnakar

Importance of Structure

At Bear Group, we primarily use Agile methodology for its flexibility and are always open to making key adjustments to accommodate major milestones and/or re-prioritizing features when needed. Nevertheless, we know from experience that allowing for too much iteration and change can cause friction between teams where a forest-through-the-trees trap can occur. Details and flexibility matter but it shouldn’t be at the expense of the client's bigger goals.

This is where we put on our consultant hats and where transparency is key: we will look for ways to include new features or adjustments — especially if critical to the project — but we’ll also clearly outline and underscore the impact that these changes can have on the schedule, budget, and overarching purpose of the project. 

Change is expected during development, and the Agile approach embraces that reality. We expect features to be re-prioritized and evolve. The discussion instead is which features are the highest priority, or should the project time be extended to make time for more features? By working collaboratively, we can adjust and prioritize in alignment with the project goals. 

If you have any questions about our Agile project management style please feel free to contact us directly to set up a time to chat.