Design on a Diet! A Lightweight DesignProcessJean-Louis (JL) MarechauxWorldwide Technical Enablement and CoP Leader – Coll...
Please note the followingIBM’s statements regarding its plans, directions, and intent are subject to change orwithdrawal w...
AgendaAgility at scale, ALM, and Architecture & DesignDesign and Backlog managementDesign and Sprint planningDesign an...
4Your work environment - Raise your hand if….1. You work on an agile project2. You team size is over 10 resources3. Your t...
5Agile scaling factors: needs for a more disciplined approach
6Quick pollAccording to agile best practices, there is no architecture in Agileprojects.TrueFalseWould you develop a sof...
7Architecture and Agile: a contradiction? No architecture role does not mean noarchitectural tasks– Architecture & design...
8<Typical agile development lifecycle (Scrum)FeedbackBacklog Sprint BacklogTasksWorking incrementTestCodeRefactorProductio...
9Agile Architecture and Design in ALM:A team approach to design management Design management is a team effort– Everyone c...
Architecture in Agile projectsSome key architectural activities your team can’t ignore, whether you are “Agile” or not: D...
AgendaAgility at scale, ALM, and Architecture & DesignDesign and Backlog managementDesign and Sprint planningDesign an...
Design information for backlog rankingBacklog ranking – Why design helps? Experimented Product Owners know that business ...
Design Management supports working as a Team Increase team knowledge throughan enterprise-wide software designrepository...
Everyone stays connected Dashboardsprovide an easyway to stayconnected withdesign activities Designcomments,recent links...
Some of the architectural and design expressions we usefor architecture envisioning/backlogprioritization/understanding15C...
AgendaAgility at scale, ALM, and Architecture & DesignDesign and Backlog managementDesign and Sprint planningDesign an...
Design information for Sprint planningSprint planning – Why design helps? Assess technical feasibility of requirements– E...
Learn from the past Quickly search across all of your organizations designs on the server for learning, review,analysis, ...
New* Architecture Decision Knowledge Architecture Decision support (ADK) Simple way to manage information aboutarchitect...
Some of the expressions we use for sprint planning – ourdistributed whiteboard for reasoning around tasks20Capability/Bloc...
AgendaAgility at scale, ALM, and Architecture & DesignDesign and Backlog managementDesign and Sprint planningDesign an...
Design to support iterative developmentDevelopment & testing – Why design helps? Sketches for ideation and problem solvin...
Live Design Documents Create livingdesigndocuments Rich textdocumentswith embeddeddesign links Add to anydesign project...
Decision
Generating or creating formal models from the informalexpressions25Informal expressions canseed the content for formalmode...
Automation: e.g. Model RESTful Services and GenerateJAX-RS Based Web Services26Generate JAX-RS basedWeb Service from Model...
Teams have visibility into coverage & completeness27 Proactively respond to gaps as they surface throughout the project ...
Some of the expressions we use during sprint featuredevelopment – our distributed whiteboard28Flow/Activity diagramsResour...
Summary: Lightweight design process for agile teams Simplicity is essential– Design Management provides simple tools Lig...
30
31Daily Apple TV giveaway Complete your session surveys online each day at a conference kiosk or onyour Innovate 2013 Por...
32Acknowledgements and disclaimers© Copyright IBM Corporation 2013. All rights reserved.– U.S. Government Users Restricted...
33© Copyright IBM Corporation 2013. All rights reserved. The informationcontained in these materials is provided for infor...
“Just Enough” Expressions and Traceability within AgileArchitecture and Design34
Upcoming SlideShare
Loading in …5
×

Innovate 2013 Design on a Diet - session 2131

534 views
502 views

Published on

Slides that Jean-Louis Marechaux and I presented at Innovate last Wednesday. Got some interesting feedback to include in the future.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
534
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Author Notes: This is the PowerPoint template for the Innovate 2013 Track Sessions This template has been built in PowerPoint 2003. If you’re using PowerPoint 2007 or above, you may experience different usability results than what is provided as guidance here. To allow all masters of your exiting presentation to be updated correctly, download this template to your hard drive and copy your existing slides into the new template using slide sorter. IBMers can find additional information on presentation guidelines and resources at: https://w3-connections.ibm.com/wikis/home?lang=en-us#!/wiki/Rational%20Presentation%20Templates,%20Guidelines,%20and%20Resources IBM Rational presenters can leverage existing brand-level assets and sparklers (including Rational Brand Messaging Slides, Client Success Slides and Client Quotes, Statistics) from SSW’s Brand Content Page: https://w3-03.sso.ibm.com/software/xl/myportal/content?synKey=R789607U42052O71 Imagery guidelines: Avoid using cartoon like clip-art, use photo-art instead. Third party material cannot be used in a presentation without written permission (this includes product and Web page screen shots, and photos). Images must be acquired from a ‘royalty-free to use’ source such as: Microsoft or Lotus Symphony Clip Art library http://www.freebyte.com/clipart_images_photos_icons/#freevectorgraphics http://www.freedigitalphotos.net/ IBMers can use royalty-free images from the following repositories : IBM Brand Systems Center / Assets / Photography Login instructions: https://w3-connections.ibm.com/forums/html/topic?id=c1082624-e54c-4e04-bad1-ddb150ac7540 IBM Software Story Images https://w3-connections.ibm.com/files/app#/collection/b7570645-b2f8-4450-a27f-9269a163fc2d IBM Rational Presentation Image Library: https://w3-connections.ibm.com/wikis/home?lang=en_US#!/wiki/Rational%20Presentation%20Templates,%20Guidelines,%20and%20Resources/page/Presentation%20Image%20Library
  • IBM IOD 2011 06/09/13 Prensenter name here.ppt 06/09/13 15:00 Please note the following IBMers must include the next slide (verbatim) after your title slide. IBMers must also include the mandatory “Acknowledgements and Disclaimers” slide (see slide 10) at the end of your presentation before the closing “Thank You” slide. - You will need to customize the “Acknowledgements and Disclaimers” text in red appropriately.
  • Get to know the audience. Identify, from the audience, some common scaling factors such as: Team size Distributed team (or collocated with some schedule arrangements)
  • In the early days, agile development was applied to projects that were small in scope and relatively straightforward. Today, organizations want to apply agile development to a broader set of projects. Agile needs to adapt to increasing complexity. Agility@Scale is about explicitly addressing the complexities that disciplined agile delivery teams face in the real world. The agile scaling factors are: Geographical distribution. What happens when the team is distributed within a building or across continents? Team size. Mainstream agile processes work well for small teams (10-15), but but what if the team is fifty people? One hundred people? One thousand people? Compliance requirement. What if regulatory issues – such as Sarbanes Oxley, ISO 9000, or FDA CFR 21 – are applicable? Domain complexity. What if the problem domain is intricate ( such as bio-chemical process monitoring or air traffic control), or is changing quickly (such as financial derivatives trading or electronic security assurance). More complex domains require greater exploration and experimentation, including but not limited to prototyping, modeling, and simulation. Organization distribution. Sometimes a project team includes members from different divisions, different partner companies, or from external services firms. Technical complexity. Working with legacy systems, multiple platforms, or blending disparate technologies can add layers of technical complexity to a solution. Sometimes the nature of the problem is very complex in its own right. Organizational complexity. The existing organizational structure and culture may reflect traditional values, increasing the complexity of adopting and scaling agile strategies. Different subgroups within the organization may have different visions as to how they should work. Individually, the strategies can be quite effective, but as a whole they simply don’t work together effectively. Enterprise discipline. Organizations want to leverage common infrastructure platforms to lower cost, reduce time to market, and to improve consistency. They need effective enterprise architecture, enterprise business modeling, strategic reuse, and portfolio management disciplines. These disciplines must work in concert with, and better yet enhance, the disciplined agile delivery processes. Each scaling factor has a range of complexities associated with it. Each team faces a different combination of factors, and therefore needs a process, team structure, and tooling environment tailored to meet their unique situation.
  • Question 1: Agile myth buster (addressed next slide) Question 2: Expected answer = 100% B. Used to introduce next slide.
  • There is no contradiction between Architecture and Agility. Misconception because the Architect role has disappeared from some agile approaches (Scrum, XP). The role still exist in OpenUP and Crystal. It is called Technical Coordinator in DSDM Design does not mean UML models or comprehensive documentation. Design is about cogitate and try to solve a specific problem Most Agile Through leaders foster architecture and design activities as part of agile approaches.
  • A team approach to design management Architecture &amp; design is a team effort Everyone contributes to design information Everyone leverages design information Backlog Priorities: business value, risks, and dependencies Sprint planning Assess technically feasible of requirements: Explore design options Evaluate development effort: Choose the right card during planning poker Development &amp; testing Sketches for ideation and problem solving Design activities intertwined with development activities Design tasks for complex user stories: Design “in a flash” Impact analysis Reduce technical debt As a developer, I need to look at design information so that I reuse available assets. As a tester, I need to consider the design information so that my script covers all the technical aspects As a team, I may want to review design information during the course of a sprint
  • Design information is used to help prioritize the backlog. Instead of just considering the business value for the user stories, pragmatic agile team take into account: Risk: address the most risky stories first Dependencies: From a technical standpoint, some user stories can be related. Sometime, one story can be addressed only when another story, or a technical component has been developed Design information help uncover risks and dependencies
  • Development effort should be assessed based on the understanding of what needs to be delivered. Design information helps the team identify what can be delivered (technical feasibility) and what can be contained in the next sprint (estimation). E valuate development effort based on level of difficulty  Choose the right card during planning poker or choose the right story points
  • Talk about the reasoning behind the decomposition, even before a work item is created “ Distributed whiteboard”
  • Problem solving: Diagrams and other information graphics can enhance human cognitive capacities in a wide range of contexts and applications Cognitive science shows the importance of visual representation to replace textual description: Sketches, drawing, diagrams, pictures Many studies in cognitive science about group creativity, analogies, pictures vs text…. “ A picture is worth a thousand words.” One study actually stated that a picture is worth 84.1 words.(http://www.cl.cam.ac.uk/~afb21/publications/Student-ESP.html) Design activities intertwined with development activities Deb, the developer, must take a look at the requirement to be sure she is developing the right feature. But she must also look at the design information to verify that her code is aligned with design choices Tanuj, the tester, is creating scripts to verify a feature. But he must also look at the design choices to check that his script is using the right components. Design “in a flash”: Quick design session, on demand, when a new technical problem is uncovered Technical dept: Use design to understand technical problems and reduce the debt. Talk about Feature Teams
  • The image shows a traceability view in Release Plan containing links to requirements and test cases. It also has a column to identify defects affecting the plan items. This demonstrates an integrated plan with traceability reporting. Rather than relying on stale and occasionally run traceability reports, using an integrated plan with a built-in traceability view makes the gaps are obvious and easy to address through out the project. The green row shows items that have no known gaps and no issues effecting the plan item. Red highlights gaps – missing requirement or missing test case Yellow indicates issues that need to be reviewed and resolved. Benefits: Creating a shared vision delivers what the stakeholders want Ensuring coverage improves quality for the release and each sprint Whole team buy-in improves team trust, efficiency and focus ` Design information is part of the lifecycle scenario. Design information is typically linked to Requirements (RM) Tasks (CCM) Test cases (QM) Design resources (DM) Tools based on OSLC facilitate lifecycle traceability
  • Also service specfications (can be textual or sequence diagrams) ...
  • Design management is part of ALM disciplines (like requirements, test, and change management) Design: Intentional yet emergent. Design is done incrementally (through Sprints), and needs are addressed when they arise. But design is also intentional (vs accidental). Some needs are anticipated. DM can be used as your distributed (and historical) whiteboard. It support agility at scale and distributed agile teams
  • Optional slide. Graphic is available in English only.
  • Giveaway Slide
  • IBM IOD 2011 06/09/13 Prensenter name here.ppt 06/09/13 15:00 Mandatory closing slide (1 of 2) Acknowledgements and disclaimers IBMers must include This mandatory “Acknowledgements and Disclaimers” slide at the end of your presentation before the closing “Thank You” slide. - You will need to customize the “Acknowledgements and Disclaimers” text in red appropriately.
  • Mandatory closing slide (2 of 2) Thank You Slide (available in English only).
  • Traceability relationships in Rational solution for CLM with focus on architecture and design Specific relationships across ALM and relationships within the design domain Steps from requirements to execution and the kind of activities in each tool in CLM Traceability to support collaborative work: explore and traverse links to understand the solution from different perspectives (dm, rm, qm, ccm) Traceability and impact analysis
  • Innovate 2013 Design on a Diet - session 2131

    1. 1. Design on a Diet! A Lightweight DesignProcessJean-Louis (JL) MarechauxWorldwide Technical Enablement and CoP Leader – Collaborative Lifecycle Managementjl.marechaux@ca.ibm.comDaniel LerouxIBM Distinguished Engineer – Architecture, Design and Engineering Lifecycle Managementdleroux@ca.ibm.comADSN-2131© 2013 IBM Corporation
    2. 2. Please note the followingIBM’s statements regarding its plans, directions, and intent are subject to change orwithdrawal without notice at IBM’s sole discretion.Information regarding potential future products is intended to outline our general productdirection and it should not be relied on in making a purchasing decision.The information mentioned regarding potential future products is not a commitment,promise, or legal obligation to deliver any material, code or functionality. Informationabout potential future products may not be incorporated into any contract. Thedevelopment, release, and timing of any future features or functionality described for ourproducts remains at our sole discretion.Performance is based on measurements and projections using standard IBMbenchmarks in a controlled environment. The actual throughput or performance that anyuser will experience will vary depending upon many factors, including considerationssuch as the amount of multiprogramming in the user’s job stream, the I/O configuration,the storage configuration, and the workload processed. Therefore, no assurance can begiven that an individual user will achieve results similar to those stated here.
    3. 3. AgendaAgility at scale, ALM, and Architecture & DesignDesign and Backlog managementDesign and Sprint planningDesign and Iterative development
    4. 4. 4Your work environment - Raise your hand if….1. You work on an agile project2. You team size is over 10 resources3. Your team use tools for planning, requirements management, tests, or change requests4. Your team is distributed5. Some team members work from home on a regular basis6. You have never raised your hand so far
    5. 5. 5Agile scaling factors: needs for a more disciplined approach
    6. 6. 6Quick pollAccording to agile best practices, there is no architecture in Agileprojects.TrueFalseWould you develop a software-intensive system without thinking?YesNo
    7. 7. 7Architecture and Agile: a contradiction? No architecture role does not mean noarchitectural tasks– Architecture & design is the responsibility of thewhole team Design activities does not necessarily implymodels or documentation– Brainstorming– Creative thinking– Problem solving Agile thought leaders recommend agilearchitecture– « Continuous attention to technical excellenceand good design enhances agility. » - Agile Manifesto,principle #9– « The best architectures, requirements, and designsemerge from self-organizing teams. » - Agile Manifesto,principle #11
    8. 8. 8<Typical agile development lifecycle (Scrum)FeedbackBacklog Sprint BacklogTasksWorking incrementTestCodeRefactorProductionIncidentsContinuousDeliveryContinuousIntegrationMany teams have adopted a similar development lifecycle, including our JazzDesign Management development team.
    9. 9. 9Agile Architecture and Design in ALM:A team approach to design management Design management is a team effort– Everyone contributes to design information– Everyone leverages information in designs– Design needs to be integrated in lifecycle, not external Design information is useful throughoutthe ALM cycle– Backlog– Planning– Sprint– Change request– Defect / incidents– Reduce technical debt– Continuous delivery– And more…… Lifecycle traceability– Requirements, design, quality, and change management– Focus on activities useful for the whole lifecycleRequirementsArchitecture &DesignQualityChange &ConfigurationCode
    10. 10. Architecture in Agile projectsSome key architectural activities your team can’t ignore, whether you are “Agile” or not: Define the approach for developing the system– Identify key best practices & patterns to leverage– Drive technical decisions Identify the appropriate technical components too meet:– Functional requirements– Non-functional requirements (availability, security, performance…) Define the structure of the system (runtime and deployment) Continuously validate architectural consistency Continuously communicate with all stakeholders (wherever they may be located) Continuously validate against (possibly volatile) requirements10Agile architecture is about finding the right balance between “anticipation” and “adaptation” Initial envisioning Evolving and emergent designSource: Succeeding with Agile, M. Cohn, 2007Source: Succeeding with Agile, M. Cohn, 2007Agile architecture is about finding the right balance between “anticipation” and “adaptation” Initial envisioning Evolving and emergent design
    11. 11. AgendaAgility at scale, ALM, and Architecture & DesignDesign and Backlog managementDesign and Sprint planningDesign and Iterative development
    12. 12. Design information for backlog rankingBacklog ranking – Why design helps? Experimented Product Owners know that business value isnot the only factor Take into account design information for ranking based on:– Risks– Dependencies– Complexity Design information helps uncover technical risks anddependencies Complex items sometimes require a design feature team tobe assigned to design scenarios and break down features
    13. 13. Design Management supports working as a Team Increase team knowledge throughan enterprise-wide software designrepository Scenario designers, analysts,architects, developers, testers, andother extended team members canaccess designs through a Webclient13Threaded discussions onscenarios and earlydesignsRich hovers provide quickaccess to information todetermine if additional detailsare required!
    14. 14. Everyone stays connected Dashboardsprovide an easyway to stayconnected withdesign activities Designcomments,recent links,most active,design reviews,design changes Create mashupdashboards withviewlets fromacross theapplicationlifecycle14
    15. 15. Some of the architectural and design expressions we usefor architecture envisioning/backlogprioritization/understanding15Component ArchitectureTactic/Scenario ModelDeployment ArchitectureLive ArchitectureDocumentsFreeForm Diagrams
    16. 16. AgendaAgility at scale, ALM, and Architecture & DesignDesign and Backlog managementDesign and Sprint planningDesign and Iterative development
    17. 17. Design information for Sprint planningSprint planning – Why design helps? Assess technical feasibility of requirements– Explore design alternatives– Leverage guidance and past decisions when possible Identify tasks to implement stories Evaluate development effort based on:– Lessons learned from the previous sprints or projects– Potentially reusable assets– Technical complexity Planning
    18. 18. Learn from the past Quickly search across all of your organizations designs on the server for learning, review,analysis, or to identify potential reuse Search directly on the server; no need to load designs into a client first Simple full text search over model content (name, description, type) Powerful query based searching18
    19. 19. New* Architecture Decision Knowledge Architecture Decision support (ADK) Simple way to manage information aboutarchitecture/design issues and decisions Other users can benefit from the decision makingprocess Leverage past decisions, understandrationale Impact analysis helps to identify decisions forspecific issues
    20. 20. Some of the expressions we use for sprint planning – ourdistributed whiteboard for reasoning around tasks20Capability/Block diagramsConceptual Data/Resource ModelDeployment ArchitectureLive ArchitectureDocumentsFreeForm Diagrams
    21. 21. AgendaAgility at scale, ALM, and Architecture & DesignDesign and Backlog managementDesign and Sprint planningDesign and Iterative development
    22. 22. Design to support iterative developmentDevelopment & testing – Why design helps? Sketches for ideation and problem solving– “A picture is worth a thousand words” Design tasks for complex user stories– Design “in a flash”– Communicate design to team Design activities intertwined with development activities– Look at design for code development– Look at design for test scripting– Various levels of automation possible Reduce technical debt– Capture design decisions for reuse, revisiting, …– Understand impact of change22
    23. 23. Live Design Documents Create livingdesigndocuments Rich textdocumentswith embeddeddesign links Add to anydesign project Keep currentas designschange23
    24. 24. Decision
    25. 25. Generating or creating formal models from the informalexpressions25Informal expressions canseed the content for formalmodelsCan convert individual shapesand connections into formalmodel elements
    26. 26. Automation: e.g. Model RESTful Services and GenerateJAX-RS Based Web Services26Generate JAX-RS basedWeb Service from ModelDeployed onApplication ServerGenerate Model fromJAX-RS based Web ServiceModel RESTful Service in RSA
    27. 27. Teams have visibility into coverage & completeness27 Proactively respond to gaps as they surface throughout the project Issues are quickly highlighted and resolved Different views available
    28. 28. Some of the expressions we use during sprint featuredevelopment – our distributed whiteboard28Flow/Activity diagramsResource/ontology modelsComponent diagramsLive ArchitectureDocumentsUse case diagrams
    29. 29. Summary: Lightweight design process for agile teams Simplicity is essential– Design Management provides simple tools Light design supports agile teams– Backlog management– Sprint planning– Iterative development during Sprints Everyone in the team creates and uses designinformation Design evolves over time– Emergent design (done incrementally)– Intentional design (decision making process)– Some design aspects may be anticipated(envisioning) Balance between anticipation and adaptation
    30. 30. 30
    31. 31. 31Daily Apple TV giveaway Complete your session surveys online each day at a conference kiosk or onyour Innovate 2013 Portal! Each day that you complete all of that day’s session surveys, your name willbe entered to win the daily Apple TV! On Wednesday be sure to complete your full conference evaluation to receiveyour free conference t-shirt!
    32. 32. 32Acknowledgements and disclaimers© Copyright IBM Corporation 2013. All rights reserved.– U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.IBM, the IBM logo, ibm.com, Rational, the Rational logo, Telelogic, the Telelogic logo, Green Hat, the Green Hat logo, and other IBM productsand services are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, orboth. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), thesesymbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks mayalso be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright andtrademark information” at www.ibm.com/legal/copytrade.shtmlIf you have mentioned trademarks that are not from IBM, please update and add the following lines:[Insert any special third-party trademark names/attributions here]Other company, product, or service names may be trademarks or service marks of others.Availability: References in this presentation to IBM products, programs, or services do not imply that they will be available in all countriesin which IBM operates.The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They are providedfor informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other guidance or advice to anyparticipant. While efforts were made to verify the completeness and accuracy of the information contained in this presentation, it is providedAS-IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwiserelated to, this presentation or any other materials. Nothing contained in this presentation is intended to, nor shall have the effect of, creatingany warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable licenseagreement governing the use of IBM software.All customer examples described are presented as illustrations of how those customers have used IBM products and the results they mayhave achieved. Actual environmental costs and performance characteristics may vary by customer. Nothing contained in these materials isintended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenuegrowth or other results.
    33. 33. 33© Copyright IBM Corporation 2013. All rights reserved. The informationcontained in these materials is provided for informational purposes only, and isprovided AS IS without warranty of any kind, express or implied. IBM shall not beresponsible for any damages arising out of the use of, or otherwise related to,these materials. Nothing contained in these materials is intended to, nor shallhave the effect of, creating any warranties or representations from IBM or itssuppliers or licensors, or altering the terms and conditions of the applicable licenseagreement governing the use of IBM software. References in these materials toIBM products, programs, or services do not imply that they will be available in allcountries in which IBM operates. Product release dates and/or capabilitiesreferenced in these materials may change at any time at IBM’s sole discretionbased on market opportunities or other factors, and are not intended to be acommitment to future product or feature availability in any way. IBM, the IBM logo,Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM productsand services are trademarks of the International Business Machines Corporation,in the United States, other countries or both. Other company, product, or servicenames may be trademarks or service marks of others.
    34. 34. “Just Enough” Expressions and Traceability within AgileArchitecture and Design34

    ×