140 likes | 152 Views
Uncover the evolution of Agile from traditional project management approaches, understand the Agile Manifesto and its principles, and learn how Agile methodologies empower people, engage customers, and deliver functionality incrementally.
E N D
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 more @ www.agilemanifesto.org) • 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 A B C AgileMan Consulting
Agile Product Delivery A B C D AgileMan Consulting
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 Side by Side Comparison AgileMan Consulting
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 Side by Side Comparison AgileMan Consulting
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 Side by Side Comparison AgileMan Consulting
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 Side by Side Comparison 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 AgileMan Consulting