Structured Agile

Agile methodology for 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. 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?

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 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 planed time and agreed budget. A product or service is analyzed and is broken down to many phases. These phases have their own backlog which are used  for features in each sprint. Phases could run in parallel or in sequence as long as they don’t depend on each others 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 divid 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 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 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 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 in every 4 to 6 weeks before costing enormousness 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 awesome collaboration feature in the market today. The time to get things done is now. Get your 1 month free trail 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 Hybrid project management method describes this process much better. From now on I will be using 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.