Structured Agile

Agile project management is all the rage these days, a Methodology used by software teams in the past 20 years has gained traction among other disciplines. A large number of project teams have switched to this project management methodology to reduce time to market and cost. Simple graphical board programs or to-do lists are touted as Agile project management applications by their vendors. These vendors claim that their software can magically make teams more productive using their boards. The only problem with this picture is that most people who claim to practice agile don’t have a deep understanding of Agile methodology and don’t realize that to do Agile correctly you need an agile team and mindset. Just calling a team Agile and using an application claiming to be agile, Scrum or Kanban doesn’t make your team an  Agile team. To be really effective in Agile and harvest its full benefits, you need to learn and practice Structured agile (some may call this methodology by other names). You may ask what is structured Agile? After all, isn’t the goal of agile to remove the structure from project management and make team collaboration and information flow the driving force for project success? This is only partly true! The above definition only applies when the project is well defined and understood in details and it is broken into many phases.

Structured Agile

what is structured Agile?

The structured agile method combines traditional waterfall or WBS models with agile methodology to have a complete understanding of the project and a viable work plan to bring a product or service to the market on time and on budget. Having understood and documented the big pictures, this methodology will set clear and focused short-term goals in order to deliver the product or service in the planned time and agreed on a budget. A product or service is analyzed and is broken down into many phases. These phases have their own backlog which is used for features in each sprint. Phases could run in parallel or in sequence as long as they don’t depend on each other’s output. A phase could have one or more sprints in duration and the product may be shipped out at the end of any phase or even sprint.

How Structured Agile works?

The structured Agile teams spend sufficient time at the beginning of a project to research the complexity of the entire project life cycle and divide the projects into many phases. Each phase will have its own backlog and will require several sprints to complete each phase. Only the first phase and its first sprint are well defined when the project development begins. At the end of each sprint, the lessons learned or changes made in the requirements by the product/business owner are used to adjust the remaining sprints. If everything goes according to the plan in a given sprint, the next sprint or phase is well defined and ready to go as soon as the current sprint is finished. If not, the team readjust the next sprints before starting the current sprint. The benefits of this approach are two-fold. First, the team has a clear understanding and goals before starting any phase of the project and can plan each phase accordingly. Second, the team can adjust its plans at the end of each sprint which should take no longer than four to six weeks due to new realities. This way a project could be adjusted or even terminated every 4 to 6 weeks before costing enormous resources and time.

If you are managing a project or a portfolio of projects in a startup, try the most flexible and affordable project management software with an awesome collaboration feature in the market today. The time to get things done is now. Get your 1-month free trial here!

Update (September 2016). The term accepted by PMI and other project management organizations for this project management methodology is called Hybrid project management. I believe the Hybrid project management method describes this process much better. From now on I will be using the Hybrid project management method exclusively.

David Robins

David Robins is the founder and CEO of Binfire. David studied at both Cornell and MIT, and was the Director of Software Engineering at Polaroid for 11 years.


Leave a Reply

Your email address will not be published.