The feature list was laid out and prioritized.  Then we grouped features together and prioritized each group based on business and technical input.  There were three overall groupings which outlined how we would develop the system. Each grouping would produce a workable solution that could be released to production to be determined by the business. 

Our team was a cohesive unit and worked very well together to overcome the many challenges that come with every project. Team meetings were happening daily to ensure progress was being made and to highlight potential obstacles.  Everyone was on board that we needed to get issues on the table as soon as possible so they could be addressed quickly to minimize risk. After each feature grouping we regrouped and discussed how we could improve and made sure our next grouping still had the correct priority.  In the end the team delivered a high quality solution that met the goals of the initiative by delivering the full solution in three chunks.  We had a very satisfied customer and a project team that did not want to stop working together. 

The year...1997.  Project methodology used...a modified Rational Unified Process (RUP), which is considered a traditional approach. Was this my first agile project?  Technically, no. The agile manifesto was not created until 2001. When describing my project you'll notice I did not use common Agile terms like Scrum, user stories, product backlog, daily stand-ups or co-located teams.  At the time of this project these terms were not defined as they are today. 

Obviously our team definitely did not use an agile methodology, but we were definitely using principles that support the Agile Manifesto. Here are some of the key principles our team lived by:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

"Working software is the primary measure of progress."

"The best architectures, requirements, and designs emerge from self-organizing teams."

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

My feeling is that the popularity of Agile development methodologies is keeping the focus off of exactly what the Agile Manifesto is trying to address.  The manifesto was developed to focus us on building better software to add value to the businesses we support. Instead of focusing on that, the focus is Agile vs. traditional methodologies. 

This week I attended the Project Summit/Business Analyst World conference in Chicago.  Agile was a topic discussed and it is clear "Wagile" and Scrumfall" methodologies are alive and well.  These are combinations of traditional and agile methodologies.  These are project methodologies that look at the skills of the team members and the culture of the organization to put in place a process that will help teams build better software. 

The moral of my story is to keep your focus on building better teams to add maximum value to the business.  Many of you are probably already focusing on the principles that support the Agile Manifesto and have been for years. Learn about new techniques that are being used and see how you can use them to improve. Don't focus on whether you are using an Agile methodology or a traditional methodology.  Do you think your business stakeholders care?  Most likely not.  They want the solutions faster, better, and cheaper to help them run the business. 

To finding your methodology,

Kupe