Agile Archeology Recall We discussed Agile Now the

Agile Archeology

Recall: We discussed Agile… • Now the Unified Process and UML and …

The Complementary Approaches: – Rational Unified Process and UML • Object Oriented Analysis and Design (OA&D) methods combined with high commercial interests of expensive Case tools brought about the integration of three prominent tools. – Object Modeling Technique (diagrams and relationships) – The Booch Method, (clouds and connections) and – Objectory (use cases) • Proponents were brought together (hired) by Rational Software Corporation and created the ‘Rational Unified Process’ (RUP).

Numerous books have been written… • Many books arose containing tons of experiences from experienced consultants, linguists, and methodologists such as – Grady Booch, – Ivar Jacobson and – James Rumbaugh (the three amigos). • They later developed the first version of UML, the second complementary work.

The RUP and UML Notation • Dominated in the last 1990 s and early 2000 s. – We used them here in Rational Rose. – Many associated apps: Clear Case, Clear Quest, …. • Defectors from this approach formed the Agile Alliance. – Disliked the heave commercialized thrust and what they considered heavyweight CASE tools. – Agilists cited RUP as bloated processware, • The RUP is a plan-driven approach with many specialized roles (see book), many discrete activities, artifacts, etc. as found in the RUP Work Breakdown Structure (WBS). • These Agilists felts the UP was very overly prescriptive. • See those chapters in your UP book.

2. 2. 1. The Unified Process • Given the rather elaborate Work Breakdown Schedule in the RUP, there arose trends to eliminate some activities / roles / artifacts deemed technically or economically infeasible. • The risk-nature of the Spiral model together w/growing concerns about software development expenses (especially from failed or challenged projects) led to leveraging the stakeholder community to exercise investment governance. • To address such concerns, distinct phase assessments and associated gates are leveraged and found in the UP architecture. – Phases (all named) represented go no-go options to proceed, among other things. • This ‘formalized’ phases (fixed) and gates is in stark contrast to the Agile approaches.

UP Lifecycle Graph – Showing Iterations STUDY THIS!!! In an iteration, you may walk through all disciplines C O N T E N T S T R U C T U R E 30 7 TIME

RUP Architecture • • • Can see the phases, iterations, and more. Hump-back Whale Chart. Can see the disciplines (core and supporting) Can see the level of effort Can see the phases and suggested iterations • Some accuse the UP of being waterfall. • Not true. UP has fixed explicit iterations. Most Agile processes have iterations too.

UP Process and Agile Comparisons. • RUP iterations were intended to produce tested, working software to be deployed to business community for feedback. Same as Agile • All core and supporting disciplines cooperate with each other in producing working products. • The expenditure of effort is captured via the additive humps in work intensity in swimlanes (vertical slices) • In some Agile approaches, there are no swimlanes of activities; rathere is a developer-centric mentality that deals with the decomposition of work.

Problems with the RUP in Practice • Commercially-driven, attempts to add more features made the RUP a framework of practices, roles, and work products (see book) – Desires to use certain CASE tools or methodologies! – Again, Clear. Case, Clear. Quest, (for requirements, testing, etc. ) and several others… • The thinking was that these roles and practices were to be instantiated to match the product to be developed. • As it turned out, more and more implementations used ‘more and more’ roles, practices, and artifacts and thus became a bloated process just like many of the older methodologies starting in the 1980 s.

RUP Improvements • Attempts to – emphasize core values and to – Get to a set of minimal core disciplines to leverage the UP architecture • have helped • But the RUP, as implemented in most cases, is viewed as a documentation-centric methodology. – Generally synonymous with plan driven, heavy-weight methodology. • Simply look at the RUP Workloads in your book.

Derivatives of UP – More Improvements • Open. UP and Essential UP are improvements. • Essential UP promotes a practiceorientation rather than a process-centric Work Breakdown Schedule. – That is the specific tasks of what you do rather than the process of how you go about doing it. • The best contribution is probably found in bringing the UP into the broader enterprise into what is alled the Enterprise UP (EUP)

2. 2. 2 Agile Methods (Scrum and XP) • The two main agile approaches resulted from developercentric frustrations with a perception of ‘ivory tower’ methodologists. – Scrum and XP – Pragmatic approaches eschewing many features of other methodologies. • These arose from several companies and project management experiences with “big requirements up front” - that typically were addressed with the Waterfall approach. • More development and more extensions evolved with specific values.

XP – Agile Methodologies • XP is usually considered the first agile approach and contributed some to Scrum. • Based on short intervals, XP is characterized by – – light-weight requirements, co-location with business partners, and a focus on core value-added activities by the developer and Theory Y Management. (Know what this is. Theory X too) • All agile practices are performed as a ‘system of practices’ each working together. • The following slide captures many features of XP

Scrum • Scrum focused on simplified approaches to project management topics of planning, estimation, progress monitoring, and reporting, • A 30 -day interval is called a Sprint with feedback loop based on the scope of the sprint. • Modern thinking in the Agile community is to view Scrum as the project management framework with XP practices used for the other disciplines. • A ‘one-pager’ on Scrum follows.

Scrum – (You have seen these…) • Scrum has a several queues such as a Product Backlog, Sprint backlog (for work management), Burn chart, and more. • The Product Backlog is the customer-managed queue of product requests owned and prioritized by the product owner. • When a sprint is started, just-in-time planning occurs with a similar queue-based approach • There is a daily Scrum meeting (daily standup) except that it is the team discussing and not a project manager. • The closest thing to a project manager in Scrum is the Scrum Master, who is more of a facilitator and runs interference for the core team when blocks or issues arise.

2. 2. 3 Lean Software Development – FDD • Feature Driven Development arose before agile • FDD arose out of a Singapore project for a large commercial lending organization. – Project was using Waterfall and was in deep trouble. • Major changes were effected such as incremental development and solid engineering techniques (like domain modeling) to resurrect the effort. • Project was turned around. Its success was attributed to what is called FDD – or Feature Driven Development.

Feature Driven Development • FDD is a model-driven, short-iteration process with five basic activities. • For reporting and tracking the project, milestones marking the progress made on each feature are defined. (shown ahead) • During the first two sequential activities, an overall model shape is established. The final three activities are iterated for each feature (hence the term, Feature Driven Development).

Five Basic Activities in Process Model

1. Develop Overall Model • Project starts with a high-level walkthrough of the system scope and its context. • Next, detailed domain walkthroughs are held for each modeling area. • For each domain (note the ‘loop’), walkthrough models are then composed by small groups, and are presented for peer review and discussion. • One of the proposed models, or a merge of them, is selected which becomes model for that domain area. • Domain area models are then merged into an overall model, and the overall model shape is adjusted along the way.

2. Build Feature List • Knowledge gathered during initial modeling is used to identify a list of features. – This is done by functionally decomposing the domain into subject areas. • Subject areas each contain business activities and categorized features. • Features in this respect are small pieces of client-valued functions expressed in the form "<action> <result> <object>", for example: 'Calculate the total of a sale' or 'Validate the password of a user'. • Features are short and should not require >= two weeks to complete; otherwise, break them into smaller pieces.

3. Plan by Feature • After the feature list had been completed, the next step is to produce the Development Plan. • Class ownership is done by ordering and assigning features (or feature sets) as classes to chief programmers.

4. Design by Feature • Design package is produced for each feature. • Chief programmer selects small group of features to be developed within two weeks. • Together with the corresponding class owners, chief programmer works out detailed sequence diagrams (behavioral modeling) for each feature and refines the overall model. • Next, the class and method prologues are written and finally a design inspection is held.

5. Build by Feature • After a successful design inspection a per feature activity designed to produce a completed clientvalued function (feature) is produced. • The class owners develop the actual code for their classes. • After a unit test and a successful code inspection, the completed feature is promoted to the main build.

Milestones • Features are small and completing a feature is a relatively small task. • For tracking, development needs to mark the progress made on each feature. • FDD therefore defines six milestones per feature that are to be completed sequentially:

Milestones per Feature • The first three milestones completed during Design By Feature activity • Last three completed during Build By Feature activity • To help with tracking, a percentage complete is assigned to each milestone. Note table: • Feature still being coded is 44% complete (Domain Walkthrough 1%, – Design 40% and – Design Inspection 3% = 44%).

FDD – Overview and Final Thoughts • FDD is interesting and has no notion of an iteration. • All is built on user stories and features constitute the central requirements and drive everything. • Increments are key and are accumulation of features • A rhythm is established and the completion and delivering features is ongoing. • Minimal features capture the central requirements and the minimal nature binds them to Agile philosophy especially the notion of a user story.

Features in FDD • Features are very simple in structure and constitute the central requirements. • Format: • <action> [a/the] <result> [of] to |for |from | … <object> [with | for | of…] <parameters>. • Example: • Verify the 2 a-7 compliance for a given trade order (for a 7/7 municipal bond).

FDD Lean • “Lean” comes from an MIT program that dealt with the Japanese and Toyota manufacturing. • How Toyota has dominated manufacturing has resulted in books on Lean Thinking. • Lean Thinking represents the abstraction of a set of core principles applied to industries beyond manufacturing. • The first usage of the term Lean Software Development was articulated in a book that represents an application of lean thinking applied to software development. • Here is a description of the twenty-two management tools:

Lean Management Tools Eliminate Waste Tool 1: Seeing Waste Tool 2: Value Stream Mapping Amplify Learning Tool 3 – Feedback Tool 4 – Iterations Tool 5 – Synchronization Tool 6 – Set-based Development

Lean Management Tools • • Decide as Late as Possible Tool 7 – Options Thinking Tool 8 – The Last Responsible Moment Tool 9 – Making Decisions • • Deliver as Fast as Possible Tool 10 – Pull Systems Tool 11 – Queuing Theory Tool 12 – Cost of Delay

Lean Management Tools • • • Empower the Team Tool 13 – Self-Determination Tool 14 – Motivation Tool 15 – Leadership Tool 16 – Expertise • • • Build Integrity in Tool 17 – Perceived Integrity Tool 18 – Conceptual Integrity Tool 19 – Refactoring Tool 20 - Testing

Lean Management Tools • See the Whole • Tool 21 – Measurements • Tool 22 - Contracts

Kanban Development • Kanban was developed based on Lean. • David Anderson, a methodologist, modified Lean to include a renewed study of FDD in conjunction with the Work-In-Progress (WIP) limiting mechanisms that were leveraged within a card mechanism used in Toyota. • They still use queueing theory which is at the basis of their productivity. • We are getting a presentation by Bryan on this.

2. 2. 4 The Hybrids (Agile-UP & Lean-Agile) • Some hybrid attempts try to ‘out iterate’ or ‘out Agile’ each other. • But good things happened in SDLC 2. 0 • Experiences from many practitioners have resulted in best practices for practical needs. • Problems with some of the processes have been in scale, management approaches, business culture, and geographical distribution.

Agile UP (Hybrid and close to our approach) • Advocate: Scott Ambler. – Reduce the roles, work products, and disciplines while still retaining UP’s core practices. • Agile-UP leverages practices that make sense within the context of a project. Examples – Test driven Development – Continuous Integration – And, a lightweight, visual approach / modeling

Agile UP (Hybrid and our approach) • Another Agile-UP hybrid by Craig Larman • Advocates: – Architecture centric governance structure of UP – Use Case practices for driving iterative and incremental development. – But Craig Larman backed off some of the Objectory-based (sequence diagrams, many levels of models) as analysis morphs into design) in favor of a Catalysis-based approach to make analysis and design more seamless. – They insert Scrum-based management and such time-boxed iterations vice deliverable-based iterations.

Agile UP (Another Hybrid – Lean Agile) • How about Scrum-ban which includes a leveraging most of the Scrum practices within an iteration that has a batch size of one. • Called Scrum-ban because it uses Lean Practices of Kanban to limit works in progress to minimize cycle time.

Kennaley’s Views on SDLC 1. 0 and 2. 0 • Mark feels SDLC 1. 0 (waterfall) should be retired, as it has run next to the 2. 0 approaches (iterative and incremental development) for many years. • He claims 2. 0 is long overdue for re-synching. • He also claims that there is still a lot of high-order waste due to the us-versus-them mud-slinging and ‘tunnel-vision that slows down the advancement of the profession. ’

Kennaley’s Views • Customers don’t care about the discussions – only want good software engineering. • Let’s get rid of the iterative wars and retire 1. 0 – the ‘accidental Waterfall misinterpretations. ” • He is after a third generation label on SDLC approaches. • Claims something ‘fundamental’ requires a major release ‘branch. ’

Kennaley’s SDLC 3. 0 • He wants to integrate all past experiences within a fundamental environment of software engineering management science. • There is no one-size-fits-all. • Rather, modern development is best served with a variety of approaches / patterns. • So, rather than pick ‘a’ method, seeking more atomic practices from multiple methods seems to be a much more reasonable approach.

Kennaley’s SDLC 3. 0 • SDLC 3. 0 brings all past experience together into a coherent baseline for future evolution to occur. • It encapsulates a focus on integration within a holistic IT value-stream; • Focuses on waste-reduction and Theory-Y management. • Rather than have a single, local genre of software engineering expertise, SDLC 3. 0 seeks to integrate, harmonize and heal competitive wounds of the past.

Kennaley’s SDLC 3. 0 • He has shown that software engineering has evolved in various flavors over the past 50 years and will continue to evolve. • But he is after a single baseline that can be modified into a single body of knowledge. • His label, SDLC 3. 0, is like a configuration. • We identify versions of software, and he suggests a SDLC 3. 1, 3. 2, etc. – Evolving.