1. John Prouty, BPMP
How I have been doing “Agile”
I have been doing business analysis before it was known as Business Analysis and have used a
variety of methods (as dictated by the customer). I have been doing agile business
development before Agile was a methodology (2001).
Here is how my experience matches up with the principles of the Agile Manifesto (as defined at
www.agilemanefesto.org):
1. Customer satisfaction by rapid delivery of useful software
At MetaPower we developed an application architecture that allows the customer to specify
business rules and directly generate application code that would implement those rules. We were
able to deliver useful software in weeks and enhancements in days.
2. Welcome changing requirements, even late in development
Our approach of application development was to quickly get the basic functionality into the hands
of the customers (in a few weeks) and then add functionality as the customer identified additional
requirements. Most applications were moved into production after 7 releases.
3. Working software is delivered frequently (weeks rather than months)
With the fully developed application architecture, we were able to deliver the initial application in
weeks (5 weeks was our record) and enhancements to the application in 1 – 3 weeks, depending
on the extent of the changes.
4. Close, daily cooperation between business people and developers
Project teams utilized client representatives (business people) to review daily (if needed) the new
business rules identified for the new functionality.
5. Projects are built around motivated individuals, who should be trusted
Project Teams were built on mutual review and support, each motivated to achieve the project
deliverable as no one owned any part of the application. Team members were not allowed to do
acceptance testing on their own work, thus everyone considered the entire product a team effort,
trusting each other to do their part.
6. Face-to-face conversation is the best form of communication (co-location)
When possible we had someone on site to review the progress of the application. Though, with
tele-conferencing technology, even off-site review worked reasonably well when on-site
communication was impractical.
7. Working software is the principal measure of progress
Project metrics tracked bug / requirement backlog based on priority needed for next minimal
functional capability. Progress toward acceptance testing was tracked based on the estimated
effort required to complete each bug / requirement. Acceptance testing metrics were tracked to
make sure all features affected by the release were tested three times, to assure the quality of
work.
8. Sustainable development, able to maintain a constant pace

2. We established a standard development life cycle that included scope definition, development,
testing, migration and delivery to the client. This allowed for a predictable set of step to be
performed for each delivery cycle. Cycle time was predictable based on the scope of the new
functionality. Established metrics for estimating coding time based on the type of features being
requested (logic change, new step, report change, new report, etc.).
9. Continuous attention to technical excellence and good design
The MetaPower architecture provided a state-of-the-art technical architecture (cloud-based) that
was infinitely expandable to meet the needs of ANY business process. This allowed for an
unrivaled agility. One customer complained that we had the software ready too soon – they
weren’t ready for it to be done.
10. Simplicity—the art of maximizing the amount of work not done—is essential
The MetaPower architecture removed all the coding of the application framework that is needed
by all applications. The only work that needed to be done to deliver an application was to teach
the system the business rules. Those rules were specified in a pseudo business language that
was understandable by the business people (business design) and at the same time automation
could translate it to executable code, eliminating the need for application programming.
11. Self-organizing teams
Our company mantra was “Do everything the MetaPower way, and if there is a better way, make
it the MetaPower way”. This gave teams the autonomy to develop tools and processes that
allowed the team to be the most efficient, given the skills and demands of the team. Under this
perspective, many new innovative tools were development that eliminated time-consuming or
repetitive programming tasks.
12. Regular adaptation to changing circumstances
The development team established a standard development life cycle that included all aspects of
application development and delivery. This process was refined as the team learned of better /
more efficient ways to work. This provided a predicable development process that management
and the client could base their expectations on.
So, although I am not certified in “Agile”, I believe that my experience puts me in a
position to meet the requirement of experience in the Agile methodology and that I can
work as the Business Analysts in a team formally utilizing the Agile methodology.