AgileMan Consulting So what the heck is Agile? It came about as a response to the high failure rate of software projects (> 60%), where failure means late, over budget or incomplete People were looking for better ways to deliver software But why were most IT projects failing?

AgileMan Consulting Traditional Software Projects Typical projects have these phases:  Estimate size of project based on high level concept  Create full set of functional requirements  Create full set of internal / technical specifications  Write the code (the fun stuff!)  Test/QA the code (less fun but very important!)  Install the new code (cross fingers & hope for the best) Each phase is discrete & usually requires official sign-off before next one can begin Resembles a waterfall, with each “step” serialized

AgileMan Consulting Why Hasn’t That Worked? Specs are hard to get right ahead of time Projects take months or years; markets can change weekly Focus is on “meeting dates,” not satisfying customers Software isn’t like manufacturing  It’s innovation, not replication  Good estimates are hard to come by!  A lot is learned in the doing

AgileMan Consulting So… What, Then? In the 1990s, Extreme Programming (XP), Scrum, Feature-Driven Development and other non-traditional approaches began emerging as people experimented In 2001, representatives of each convened to look for commonalities between them What did they find?

AgileMan Consulting The Agile Manifesto Some common principles were discovered “We value:  People & interactions over Processes & tools  Customer collaboration over Contract negotiation  Responding to change over Following a plan  Working software over Comprehensive documentation” (read But what does any of that mean?

AgileMan Consulting Agile: The 30,000 Foot View Agile methodologies are all about:  Empowering & engaging people at all levels  Keeping the customer involved throughout  Allowing for flexibility  Delivering functionality incrementally (in short Iterations… sometimes as little as 1 week!)  Using short feedback loops to drive adaptation How is that any different from traditional (“Waterfall”) software development?

AgileMan Consulting Waterfall Product Delivery

AgileMan Consulting Agile Product Delivery

AgileMan Consulting Side by Side Comparison Waterfall:  Large, upfront design & specifications  Changes often result in waste (abandoned work)  Everything arrives at end of project (hopefully!) Agile:  “Just in time” design & specifications  Changes are expected and typically don’t cause waste  Features are delivered incrementally throughout project

AgileMan Consulting Side by Side Comparison Waterfall:  Customer involved at start & end of project only  Mid-project demos expensive & often misleading  Project status often unclear or inaccurate Agile:  Customer involved throughout, feedback acted upon  Working software arrives each Iteration as part of plan (no “Demoware”)  Project status updated frequently & demonstrably

AgileMan Consulting Side by Side Comparison Waterfall:  Most testing occurs at end of project (near deadline)  Testing typically done manually (in QA cycle at end of project)  Stakeholders focus on adhering to plan Agile:  Testing happens in every Iteration throughout project  Emphasis placed on automating testing (so that it can be done throughout)  Stakeholders focus on delivering customer value in priority order

AgileMan Consulting Side by Side Comparison Waterfall:  No time allocated in plan for process improvement  Developers & testers are directed by management on what tasks to work on Agile:  “Inspect & Adapt” is built into process & accounted for  Team members are self-directed & encouraged to find better ways to work

AgileMan Consulting So How Does Agile Work? Customer asks for something or builds a prioritized queue of requests Agile team works with Customer to understand what’s really being asked for Agile team sizes each request as it comes in Agile team breaks top priority item(s) into small pieces that can be delivered in a short Iteration Agile team produces those pieces, “done done done” (tested, documented, free of known defects)

AgileMan Consulting So How Does Agile Work? Customer tries out each piece as it comes, provides feedback Partial functionality may / may not go into production Scope of overall project will change as circumstances allow (or dictate)  If project is date-bound, customer gets as many high priority features as possible by end date  If project is feature-bound, customer gets full set of features by earliest possible date