Presentation on theme: "Agile Software Development: What’s Really Going On Scott W"— Presentation transcript:
1Agile Software Development: What’s Really Going On Scott W Agile Software Development: What’s Really Going On Scott W. Ambler Practice Leader Agile Development
2Scott Ambler - Background Practice Leader Agile DevelopmentFellow – International Association of Software Architectswww-306.ibm.com/software/rational/bios/ambler.html
3Presentation Overview Warning!Agile Software Development (ASD)Agile Adoption RatesGoing Beyond the Extreme Rhetoric
4Warning! I’m spectacularly blunt at times Many new ideas will be presentedSome may not fit well into your existing environmentSome will challenge your existing notions about software developmentSome will confirm your unvoiced suspicionsDon’t make any “career-ending moves”Be skeptical but open minded
5Agile Software Development (ASD) What is ASD?How it’s differentMythbustersWhy does ASD Work?Some Common Practices
6What is Agile? Core principles An iterative and incremental (evolutionary) approach performed in a highly collaborative manner with just the right amount of ceremony to produce high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders.Core principles“Fits just right” processContinuous testing and validationConsistent team collaborationRapid response to changeOngoing customer involvementFrequent delivery of working softwareAgile can mean different things to different people, so it can be helpful to create some common ground to avoid misunderstandings. As IBM Rational has worked with companies who are undertaking Agile Development, we’ve made some key observations:Agile software development can be significantly different from one organization to another. Agile is not a “one size fits all” propositionAgilists do a lot more testing, in fact they often write a test before they write sufficient production code to fulfill that test, then they iterateAgilists work very closely together and ideally work closely with their stakeholdersChanging requirements are seen as a competitive advantage, as long as you can act on them, not as something that you need to preventAgilists deliver working software every iteration, providing concrete evidence of actual progress on the project. Daily builds, or even multiple times a day are highly desirableShorter iterations are desirable, from as short as one-to-two weeks, 4 weeks as a common recommendation, although up to 8 weeks will occur at scale
7How Agile is Different Focus on collaboration: Less paperwork and more conversationStakeholders actively involvedFocus on working software:Greater feedback makes agile projects easier to manageLess documentation is requiredLess bureaucracyAgilists are generalizing specialists:Less hand offs between peopleLess people requiredSpecialists find it difficult at first to fit into the teamAgile is based on practice, not theory:This is a significant change from traditionalYou need to see how agile works in practice to truly understand it
8Mythbusters Myth Reality No Documentation Undisciplined No Planning Not PredictableDoes Not ScaleIs a FadSilver BulletRUP isn’t agileNot Fixed PriceRealityAgile DocumentationRequires great disciplineJust-in-time (JIT) planningFar more predictableEclipse is agileIt’s quickly becoming the normIt requires skilled peopleRUP is as agile as you make itAgile provides stakeholders control over the budget, schedule, and scope
9Why Agile Works www.ambysoft.com/essays/whyAgileWorksFeedback.htm
10Some Common Practices Regular Deployment of Working Software Pair ProgrammingRefactoringContinuous IntegrationTest Driven Development (TDD)Shared Code OwnershipActive Stakeholder Participation
11Have you Adopted Agile? Number of Projects Run Success Rates Agile Adoption Rates*Have you Adopted Agile?Number of Projects RunSuccess Rates*Figures from an April 2007 Survey to be summarized in the August 2007 issue of Dr. Dobb’s Journal
12Has Your Organization Adopted One or More Agile Techniques?
15Going Beyond the Extreme Rhetoric Modeling and DocumentationRational Unified Process (RUP)TestingDatabase RefactoringDatabase Regression TestingGovernance
16Agile Model Driven Development (AMDD) Project Level www. agilemodeling Agile Model Driven Development (AMDD) Project Level
17Agile Documentation Document the stable, not the speculative Agile documents:Maximize stakeholder ROIDescribe “good things to know”Have a specific customer and facilitate the work efforts of that customerAre sufficiently accurate, consistent, and detailed
19Agile Testing www.ddj.com/dept/debug/196603549?cid=Ambysoft Regression testing is critical to the success of evolutionary (iterative and incremental) developmentAcceptance tests are considered to be primary requirements artifactsUnit tests are considered to be detailed design artifacts
20Database RefactoringA database refactoring is a simple change to a database schema that improves its design while retaining both its behavioral and informational semantics. Examples: Move Column, Rename Table, and Replace Blob With Table.A database schema includes both structural aspects such as table and view definitions as well as functional aspects such as stored procedures and triggers.Important: Database refactorings are a subset of schema transformations, but they do not add functionality.
22Agility at Scale: “Right-Sizing” Governance Pragmatic Governance BodyStaged Program DeliveryManage Project Pipeline By Business ValueScenario-Driven DevelopmentIterative DevelopmentAdapt The ProcessRisk-Based MilestonesContinuous ImprovementEmbedded ComplianceSimple And Relevant MetricsContinuous Project MonitoringOrganization& MeetingsProcessesMission & PrinciplesMeasuresOther industries has gone through a major paradigm shift over the last 50 years. In the 70s, Toyota launched the Toyota Manufacturing Systems which revolutionized how the car industry is run, with concepts such as self-organized teams, continuous improvements (kai-zen), and more agile governance structures, where e.g. any factory worker was allowed to stop production if they say a quality problem. Similarly, Walmart has lead a revolution in the retail industry where you have much more of a collaborative governance model with supplier and buyer working hand in hand to enable an adaptive model enabling inventories to be adjusted rapidly to meet demands and fluctuations caused by hurricanes or holidays. In the same way, modern military has moved from a strict command and control to a structure of steer by objective and self governed teams with accountability. A platoon is given the authority to adapt to reality and find the best possible path to accomplish established objectives. We are starting to see the same paradigm shift in the software industry, and we have captured a set of practices that captures this new approach to governance, or "right-sizing governance".INTRO TO THIS SLIDE:Traditional governance is often based on a command-and-control mindset, something that doesn’t work well for intellectual workers.Traditional governance is often described as trying to herd cats. You can’t herd cats.To govern Agile projects, and in an effective manner in general, you want to:Take a collaborative approach with IT professionalsInvolve them with decisions, respect their expertiseThe key is that governance will likely happen whether you want it to or not. The key is to be PROACTIVE about governance instead of REACTIVE. That way you will have greater influence over how the organization will address these issues.DETAILED DISCUSSION OF Practices/Patterns:Pragmatic Governance Body – cost effective techniques, focus on enabling development teams, not controlling themStaged Program Delivery – roll out the program in chunks / increments. Subprojects must sign up to release date. If subproject misses, it skips to the next release, but this minimizes the impact to customers.Manage Project Pipeline by Business Value – invest in the projects that make the most sense, with less focus on “cool technology”Iterative Development – incremental approach to development. Build a system in time-boxes, not as a single-big bang effortAdapt the Process – one process size does not fit all, tailor the process to meet a team’s exact needs. Processes must be evaluated and evolve over time. Shouldn’t have a “because we’ve always done it that way” mentalityRisk-based Milestones – huge feature of RUP, Mitigate business, technical, … risk early in the lifecycleContinuous Improvement – Identify and act on lessons learned throughout the project, not just at the endEmbedded Compliance – Build in compliance into your day-to-day process, do not have a separate compliance process which causes unnecessary overhead. Automation is criticalSimple and Relevant Metrics – Automate metrics collection, minimize the number of metrics collected, know why you’re collecting themContinuous Project Monitoring – Use automated metrics to monitor projects, identify potential issues and work with teams to resolve them earlyIntegrated Lifecycle Environment – Automate as much of the drudge work as possible, tools and processes should fit together effectively throughout the lifecycle.Valued Corporate Assets – People should follow guidance, reuse assets, and conform to common infrastructure because these things add value, not because they’re forced to do so. Make it easier to follow existing guidelines rather than creating their own.Flexible Architectures – SOA, components, objects, patterns, … lead to greater levels of consistency, reuse, enhancability, and adaptabilitySelf-Organizing Teams – IT professionals are intelligent people who can determine their own strategies for working, for planning their work within established parameters (such as iteration boundaries) and are provided the right coaching.Align HR Policies with IT Values – Hiring, retaining, and promoting technical staff requires different strategies than non-technical staff. Promote rewards for people to learn new skills. Limit bureaucracy, and put incentives/rewards in place for timely delivery or other key accomplishments.Align Organization Structure With Architecture – Distributed teams motivate you to have partitioned architecturesRoles &ResponsibilitiesPolicies &StandardsSelf-Organizing TeamsAlign HR Policies With IT ValuesAlign Organization Structure With ArchitectureIntegrated Lifecycle EnvironmentValued Corporate AssetsFlexible Architectures
23Scott W. Ambler www-306.ibm.com/software/rational/bios/ambler.html Keep In Touch!Scott W. Amblerwww-306.ibm.com/software/rational/bios/ambler.html
24References and Recommended Reading Ambler, S.W. (2002). Agile Modeling: Effective Practices for XP and the UP. New York: John Wiley & Sons.Ambler, S.W. (2003). Agile Database Techniques. New York: John Wiley & Sons.Ambler, S.W. (2004). The Object Primer 3rd Edition: AMDD with UML 2. New York: Cambridge University Press.Ambler, S.W. and Sadalage, P.J. (2006). Refactoring Databases: Evolutionary Database Design. Reading, MA: Addison Wesley Longman, Inc.Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide. Reading, MA: Addison WesleyMcGovern, J., Ambler, S.W., Stevens, M., Linn, J., Sharan, V., & Jo, E. (2003). The Practical Guide to Enterprise Architecture. Prentice Hall PTR.