Key Points

1. basic delivery process: assessment = reqmts, design = design, build = develop, test, implement, support
2. Software delivery steps for new solutions:  define > design > plan > deliver > test > implement > support
3. different domains: business, system, data, services, infrastructure
4. different metadata and modeling for domains - are repositories reusable? how?
5. different tools for modeling in a domain
6. object-oriented design is the natural method of expression for systems concepts - goes back 50,000 years
7. CAC is more important than inheritance ( Composition, Association, Collaboration ) in OO models and runtimes
8. Use diagrams or pseudo code ?
   1. diagrams done right can say a lot but generally have a high cost to create and maintain
   2. pseudo code can be expressive if done right with the right levels of abstraction and using user terminology but may not be as communicative as diagrams
9. Architecture standards:  TOGAF, ITIL, BIAN, UML
10. Agile concepts - Agile, SAFE, Scrum, Programs, Releases, Sprints, Epics, Stories, Use cases, Test cases
11. Project Management Keys - business, project, technical, resources
12. Enterprise Architecture provides support throughout solution delivery process for new and existing projects
    1. solution architecture supports functional requirements
    2. enterprise architecture supports non-functional requirements
13. While each system should be designed with the appropriate design models and processes it is common to have:
    1. user journey flow for each key user type in the system showing the: pains, delights, decisions and feelings a user has over key system interactions
       1. if the new system is a replacement or upgrade, show both the old and new user journeys to understand the net impact for each audience
    2. key system process flows rows for process states / events, columns for key actors, top level system apis, top level shared DB updates
       1. for a distributed system, may need to show multiple systems ( eg a supplier and a consumer system etc )
14. Where possible, build visual models from specifications vs diagrams
    1. good tools create models from code and generate code from models
       1. at a minimum, good tools at least generate the related test cases
    2. diagrams are just pictures

References

Key Concepts

Jim Change Management Concepts

3 work areas:  support, operations, projects

Project Life Cycle:  3DIMS

1. New or Existing Solutions
   1. Define, Design, Plan, Deliver, Implement, Measure, Support
   2. Define current system and the need for change, vision, scope, requirements, change concepts and strategies  ( POT? )
   3. Design the new solution - ( POC? or POV? ) - journeys, processes, metrics, services, solutions, executable test cases
   4. Plan the solution given a concrete design - deliverables, teams, roles, scope, success metrics
   5. Deliver - SAFE or Agile processes, environments, test cases, 3B resources ( borrow, buy, build ), test
   6. Measure - measure actual results against expected KPI's
   7. Support and Improve

Project Management

1. GAPS - Goals, Assumptions, Problems, Solutions
2. OARS - Objectives, Assumptions, Reviews, Steps

Success Factors - VCRS -

1. Value, Cost, Risks, Support

Impact and Opportunity Factor Assessment - FACTUR3.IO

1. Feelings, Accuracy, Cost, Timeliness, Utility, R3 ( Risks, Resources, Revenues ),
2. I = the input ( current state ).  O = the output or target state

Architecture Themes

m Design Engineering Themes

BOCETSSSMQT

1. BPE - Business Process Engineering
2. CIP - Continuous Improvement Process Team
3. CDS - Customer Driven Solutions
4. EOS - Enterprise Open-Source
5. TDD - Test Driven Delivery
6. SDS - Smart Data Services
7. SSM - Smart Service Management
8. SOE - Service-Oriented Engineering
9. SDD - Sprint Driven Delivery
10. MDG - Model Driven Generation
11. QMS - Quality Management Services
12. T3 - Right Tools, Training and Tallent
13. VE - Validate Everything - trustless model
14. VCN - Value Chain Networking analysis model for each role

In-sourcing with Quick Web Workshops

As a technology consultant I didn't have a skilled work force to run digital transformation projects so I "in-sourced" instead of "out-sourcing". My father used to say: "Consultants borrow your watch to tell you the time". I modified that to "I'll borrow your workforce to get this new project done".

I engineered projects so that I could train the workforce in a week or two to deliver a large part of the project. I would automate other parts of the deliverable where possible.

The end result? I had a very knowledgeable, motivated team that picked up new skills, understood the business and current systems well and was ready to support the delivered solution. Not rocket science.

Top level design artifacts

Where possible, create models vs diagrams

models can be visual but can also generate code ( eg UML to DDL etc )

Business Use Case Model

Defines business scope and use case list

If needed, represent key use case relations and dependencies

Business Context Layer Model

key business processes modeled for top level use cases

Maybe business context diagrams for key use cases

Typically shows multiple participants ( businesses or departments depending on scope ) in the VCN

Highlights VSM events

Application Services Layer Model

Top level User - System interaction models

B2B interaction models for B2B processes

Enterprise Architecture - Tiers and Layers View

aka the "stack" view of producers and consumers

logically layered from

business model

VSP - value stream process model

incorporates both activities and decisions participants make

app model

services model

decision model

information model

infrastructure model

Solutions evolve over time from new or changed business or infrastructure requirements

This is an update to the simple 4 domain TOGAF architecture

lays the foundation for AI, RI, VCN etc

Data Model for Key Entities and Relations

For Key Process Objects, id key states / events

Current and Future State Analysis

1. Document systems, actors, goals, key metrics, system flows, entities, entity life cycles, key events, key decisions, transaction flows, data models, analytics models, GRC solutions
2. Document who and why change is needed
3. Document concepts for change - what, why, how, who, when, how much, why not
4. FACTUR3.IO analysis on issues and opportunities for new state
   1. Feelings, Accuracy, Costs, Timeliness, Utility, Risks on Impacts and Opportunities
5. Review existing system models as context for new system
6. Model the new system and related infrastructure changes
7. Consider architecture themes: BPM, OIP, EOS, CDS, TDD, SDM, SSM, SOE, QM, MDG, T3
8. Review sponsors, champion visions, commitments to the change
9. Define goals, responsibilities, objectives, metrics, acceptance criteria for project and operations, risk mitigation ( business, project, technology, resources )

Object Design Models for requirements

1. natural method to specify structure, behavior, responsibilities, capabilities with metadata support
2. supports natural system modeling from a user view
3. supports round-trip engineering using metadata
4. primary interaction methods:  composition, association, collaboration
5. inheritance and typeOf are optional constructs to use only in the right use case

Digital Transformation Concepts

https://www.slideshare.net/KelltonTech/api-strategy-with-ibm-api-connect

Enterprise Architecture

Defines the overall architecture for business information systems.

Focuses on the non-functional requirements for solutions

Provides a long-term model for managing IT

Tiers and Layers models of business information systems

1. Layers:  business > applications > services > data flows > network > stores > assets
2. Tiers:  client > network > server

Value Analytics

Value Stream Mapping for a process

https://www.lucidchart.com/pages/value-stream-mapping

https://drive.google.com/open?id=1bpoWVlnQob4SuNMkybIISqGqperneJmO

Value Chain Networking for independent entities

User Journeys

Beginner's Guide to User Journeys

https://uxplanet.org/a-beginners-guide-to-user-journey-mapping-bd914f4c517c

The 8-steps process of user journey mapping

Choose a scope. ...
Create a user persona. ...
Define scenario and user expectations. ...
Create a list of touchpoints. ...
Take user intention into account. ...
Sketch the journey. ...
Consider a user's emotional state during each step of interaction. ...
Validate and refine user journey.

User Journey Template

User Journey Decision Model Extension - SWT - add decisions to pain points, delights, feelings

User Journeys show the user's

1. pain points
2. delight moments
3. feelings

Now add user decision points

at each step

1. model the decisions the user makes
2. define the input data for each decision
3. define the algorithms for the decision

User Journeys and User Flows

https://medium.com/sketch-app-sources/user-journey-maps-or-user-flows-what-to-do-first-48e825e73aa8

user-flows-medium.com-User Journey Maps or User Flows what to do first.pdf

User Flows

User Flows focus on a path often actions to perform. Makes easy to validate if the solution’s processes are complete. User Flows make the solution easy to understand to the team almost instantly.

UX Flow may not be linear — it contains decision nodes, paths, modes, and loops that show all possible interactions with the product.

Usually flows do not focus on users feeling or multiple layers of the solution. Their main purpose is to visualize the flow through the solution.

User Journeys

Journey Maps focus on more on the experience of the customer, try to detect pain points or moments of delight. They may focus on different aspects of a solution, not only the mobile app but also the back-end server.

While User Flows have got more formal rules (probably because their flowchart origins), Customer Journey Maps are very various. There are examples around the web of maps that are very different from each other.

TOGAF - The Object Group Architecture Framework

https://www.opengroup.org/togaf

TOGAF introduction

http://www.opengroup.org/library/w182

TOGAF reference cards

https://publications.opengroup.org/n180

TOGAF concepts

togaf-concepts-2018-cio-mag.pdf

TOGAF overview

TOGAF_oveview_2007_Lankhorst.pdf

Archimate modeling language

The ArchiMate^® modelling language is an open and independent Enterprise Architecture standard that supports the description, analysis and visualisation of architecture within and across business domains. ArchiMate is one of the open standards hosted by The Open Group^® and is fully aligned with TOGAF^®. ArchiMate aids stakeholders in assessing the impact of design choices and changes.

archimate 3.0 spec

https://publications.opengroup.org/c179

business structure

application behavior

Process dependency relationships 

Archi modeling tool - the TOGAF modeling tool

https://www.archimatetool.com/

The Archi^® modelling toolkit is targeted toward all levels of Enterprise Architects and Modellers. It provides a low cost to entry solution to users who may be making their first steps in the ArchiMate modelling language, or who are looking for an open source, cross-platform ArchiMate modelling tool for their company or institution and wish to engage with the language within a TOGAF^® or other Enterprise Architecture framework.

Base Archimate is now open-source software

UML Basics

https://tallyfy.com/uml-diagram/

Behavioral UML Diagram

• Activity Diagram
• Use Case Diagram
• Interaction Overview Diagram
• Timing Diagram
• State Machine Diagram
• Communication Diagram
• Sequence Diagram

Structural UML Diagram

• Class Diagram
• Object Diagram
• Component Diagram
• Composite Structure Diagram
• Deployment Diagram
• Package Diagram
• Profile Diagram

Class Diagram

1. UML Class - Like CRC card - name, purpose, attributes, behaviors, implements
   1. attributes and methods are public, private or protected
2. Class relationships - uses, consumes, produces, inherits - shows cardinality, role names
   1. association shows direction -  A to B, B to A, both A B
   2. composition shows a diamond arrow

Composition is a strong association in which the part can belong to only one whole -- the part cannot exist without the whole. Composition is denoted by a filled diamond at the whole end.

Aggregation is a kind of "light” composition (semantics open, to be accommodate to user needs). Aggregation is denoted by a empty diamond at the whole end

A dependency is a relation between two classes in which a change in one may force changes in the other. Dependencies are drawn as dotted lines.

A constraint is a condition that every implementation of the design must satisfy. Constraints are written in curly braces { }.

Object diagrams

Object diagrams show instances instead of classes. They are useful for explaining small pieces with complicated relationships, especially recursive relationships.

Each rectangle in the object diagram corresponds to a single instance. Instance names are underlined in UML diagrams.

Class or instance names may be omitted from object diagrams as long as the diagram meaning is still clear

Action Diagrams

Sequence Diagrams

Component Diagrams

Deployment Diagrams

Conceptual Architecture Diagram

Combines Deployment and Action for use case Actors

Other UML Diagrams

Timing Diagrams

JEPL - Jims Event Process Language

simple object-based process flows based on events, outcomes

event / condition >  actor >  actions > outcomes

the events / condition step can reference other outcome labels as input events

creates a static flow

to view real sequences, need to execute groovy dynamic models using DSL and expando with default printString outputs to console

works ok for conceptual system process flows

REST API Design

https://www.guru99.com/soa-principles.html       SOA principles summary

https://swagger.io/docs/       OpenAPI for REST design docs

m REST API design and tools       OpenAPI details

Flowchart Basics

https://en.wikipedia.org/wiki/Flowchart

Flowchart symbol cheat sheet

https://www.breezetree.com/articles/flow-chart-symbols

Flowchart symbol types

types of flowcharts

Decision flowcharts, logic flowcharts, systems flowcharts, product flowcharts, and process flowcharts are just a few of the different types of flowcharts that are used in business and government

BPM example

https://en.wikipedia.org/wiki/Business_process_mapping

State life cycle diagrams

https://en.wikipedia.org/wiki/State_diagram

good for MDM and transaction state ( eg orders, shipments etc )

Data flow diagrams

https://en.wikipedia.org/wiki/Data-flow_diagram

When using UML, the activity diagram typically takes over the role of the data-flow diagram.

ERD - Entity Relationship Diagram

used to show relationships between data or object types

Activity Diagrams for process & decision flows

https://en.wikipedia.org/wiki/Activity_diagram

combine functional flowchart and data flow ( or state ) diagrams

Activity diagrams are constructed from a limited number of shapes, connected with arrows.^[4] The most important shape types:

• ellipses represent actions;
• diamonds represent decisions;
• bars represent the start (split) or end (join) of concurrent activities;
• a black circle represents the start (initial node) of the workflow;
• an encircled black circle represents the end (final node).

Arrows run from the start towards the end and represent the order in which activities happen.

Can be useful for decision flows

BPM modeling methods

https://tallyfy.com/business-process-modeling-techniques/

using business process modeling techniques:

• You can spot tasks that are redundant and eliminate them.
• You can improve process efficiency by looking for areas where work gets held up because of bottlenecks in the process.
• You can ensure that efficient processes are repeated in the same way every time, even when a new staffer must perform part of the process.

BPMN

1. Flow objects:
   Events are represented by circles, activities fit into rectangular boxes with rounded corners, and gateways or control points are represented with diamond shapes.
2. Connecting objects:
   Since tasks are interconnected, we join them up to show their sequence. Solid lines indicate task transfers, and dashed ones indicate messages.
3. Swim lanes:
   A single sub-process in your workflow could require the sharing of responsibility. Swim lanes detail how these shared responsibilities are distributed and how they interact. The sub-task is the “pool” and the “lanes” represent people or departments.

4. Artifacts:

   If you need to add extra information that isn’t a sequence flow or message flow but that helps to explain a process, you can use artifacts. Dotted lines point to the flow object the extra information expands on. Squares outlined with dots and dashes group elements in the diagram, and text annotations are added with a square bracket.

Business Process with Swim lanes for Responsibilities

System Process Flow with Infrastructure Tiers and Process Step Layers

Note: normally this system process flow would have the infrastructure tiers as shown but would have major process sequences vertically,

BPM with Artifacts

Data Flow Diagrams for a Process

For given process, connect:

Entities, processes, information flows, events

Book a room example

Functional Flow Diagrams

focus is the order of execution of tasks or functions in a sequence of ordered blocks.

Can break down to HIPO - hierarchical input process output diagrams

Gantt Chart

summarizes major tasks in time period sequence to reflect start, stop times and dependencies

PERT Chart

Program Evaluation and Review Technique (PERT) diagrams, which seek to break business process flows into timelines by estimating the shortest, longest, and likeliest times for the completion of each step in a business process.

helpful in setting goals and targets and in comparing different process approaches to determine which will be more efficient

BIAN - Banking Industry Architecture Network

https://www.bian.org/deliverables/

The BIAN model is based on a service-oriented architecture that defines the standard business capabilities that make up a bank- such as payments, loan offerings or trading facilities.

BIAN is in partnership with independent standards bodies such as Object Management Group (OMG) and The Open Group. In addition, BIAN has a ‘category D liaison’ with the International Organisation for Standardisation (ISO), for ISO 20022 semantic models.

The BIAN “How-to Guide” is a comprehensive set of documents. Aimed at audiences including technical architects, BIAN members and other financial institutions

Together this network of professionals is dedicated to lowering the cost of banking and boosting speed to innovation in the industry. Members combine their industry expertise to define a revolutionary banking technology framework that standardises and simplifies core banking architecture, which has typically been convoluted and outdated. Based on service oriented architecture principles, the comprehensive model provides a future-proofed solution for banks that fosters industry collaboration.

https://www.bian.org/deliverables/bian-how-to-guide/

The BIAN “How-to Guide” is a comprehensive set of documents. Aimed at audiences including technical architects, BIAN members and other financial institutions, the guides detail the theory and design practices behind the BIAN Service Landscape, the tools and templates used to capture content and directions for applying the BIAN Standard in your technical and business environment.

• BIAN How-to Guide – Introduction to BIAN v7.0
• BIAN How-to Guide – Design Principles Techniques v7.0
• BIAN How-to Guide – Developing Content v7.0
• BIAN How-to Guide – Applying the BIAN Standard v7.0
• BIAN How-to Guide – Semantic API V7.0

The  “How-to Guide” gives organisations a toolset for using and implementing the BIAN model in their own organisations.

BIAN Service Message API Formats

https://static.bian.org/wp-content/uploads/2015/01/FINALBIAN_CMU_Final_Report.pdf

IDEF models - Integrated Definition

https://www.edrawsoft.com/what-is-idef.php

graphical Process Modeling Methodology used to implement systems and engineer software. These methods are used in data functional modeling, simulation, object-oriented analysis, and knowledge acquisition.

SOA - Service-Oriented Architecture

Principles

service-oriented architecture (SOA) is an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network

1. Standardized Service Contract - Services adhere to a service description. A service must have some sort of description which describes what the service is about. This makes it easier for client applications to understand what the service does.
2. Loose Coupling – Less dependency on each other. This is one of the main characteristics of web services which just states that there should be as less dependency as possible between the web services and the client invoking the web service. So if the service functionality changes at any point in time, it should not break the client application or stop it from working.
3. Service Abstraction - Services hide the logic they encapsulate from the outside world. The service should not expose how it executes its functionality; it should just tell the client application on what it does and not on how it does it.
4. Service Reusability - Logic is divided into services with the intent of maximizing reuse. In any development company re-usability is a big topic because obviously one wouldn't want to spend time and effort building the same code again and again across multiple applications which require them. Hence, once the code for a web service is written it should have the ability work with various application types.
5. Service Autonomy - Services should have control over the logic they encapsulate. The service knows everything on what functionality it offers and hence should also have complete control over the code it contains.
6. Service Statelessness - Ideally, services should be stateless. This means that services should not withhold information from one state to the other. This would need to be done from either the client application. An example can be an order placed on a shopping site. Now you can have a web service which gives you the price of a particular item. But if the items are added to a shopping cart and the web page navigates to the page where you do the payment, the responsibility of the price of the item to be transferred to the payment page should not be done by the web service. Instead, it needs to be done by the web application.
7. Service Discoverability - Services can be discovered (usually in a service registry). We have already seen this in the concept of the UDDI, which performs a registry which can hold information about the web service.
8. Service Composability - Services break big problems into little problems. One should never embed all functionality of an application into one single service but instead, break the service down into modules each with a separate business functionality.
9. Service Interoperability - Services should use standards that allow diverse subscribers to use the service. In web services, standards as XML and communication over HTTP is used to ensure it conforms to this principle.

Key Documents by Project Stage

ITIL version 2

The eight ITIL Version 2 books and their disciplines are:

The IT service management sets

1. Service Support 2. Service Delivery

Other operational guidance

3. ICT infrastructure management 4. Security management 5. Application management 6. Software asset management

To assist with the implementation of ITIL practices a further book was published (Apr 9, 2002) providing guidance on implementation (mainly of Service Management):

7. Planning to implement service management

And this has more recently (Jan 26, 2006) been supplemented with guidelines for smaller IT units, not included in the original eight publications:

8. ITIL small-scale implementation

Service support

The Service Support^[33] ITIL discipline focuses on the User of the ICT services and is primarily concerned with ensuring that they have access to the appropriate services to support the business functions.

To a business, customers and users are the entry point to the process model. They get involved in service support by:

• Asking for changes
• Needing communication, updates
• Having difficulties, queries
• Real process delivery

The service desk functions are the single contact-point for end-users' incidents. Its first function is always to document ("create") an incident. If there is a direct solution, it attempts to resolve the incident at the first level. If the service desk cannot solve the incident then it is passed to a 2nd/3rd level group within the incident management system. Incidents can initiate a chain of processes: incident management, problem management, change management, release management and configuration management. This chain of processes is tracked using the configuration management database (CMDB), - ITIL refers to configuration management system (CMS), which records each process, and creates output documents for traceability (quality management). Note - CMDB/CMS does not have to be a single database. The solution can be Federated.

Service delivery

The service delivery^[34] discipline concentrates on the proactive services the ICT must deliver to provide adequate support to business users. It focuses on the business as the customer of the ICT services (compare with: service support). The discipline consisted of the following processes:

• Service level management
• Capacity management
• IT service continuity management
• Availability management
• Financial management

ICT infrastructure management

Information and Communication Technology (ICT) management^[35] processes recommend best practice for requirements analysis, planning, design, deployment and ongoing operations management and technical support of an ICT infrastructure.

The infrastructure management processes describe those processes within ITIL that directly relate to the ICT equipment and software that is involved in providing ICT services to customers.

• ICT design and planning
• ICT deployment
• ICT operations
• ICT technical support

These disciplines are less well understood than those of service management and therefore often some of their content is believed to be covered 'by implication' in service management disciplines.

12 Factor App Design

https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology#The_Twelve_Factors

MVVM - front-end app pattern

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel

Model–view–viewmodel (MVVM) is a software architectural pattern.

MVVM facilitates a separation of development of the graphical user interface – be it via a markup language or GUI code – from development of the business logic or back-end logic (the data model). The view model of MVVM is a value converter,^[1] meaning the view model is responsible for exposing (converting) the data objects from the model in such a way that objects are easily managed and presented. In this respect, the view model is more model than view, and handles most if not all of the view's display logic.^[1] The view model may implement a mediator pattern, organizing access to the back-end logic around the set of use cases supported by the view.

issues

for larger applications, generalizing the ViewModel becomes more difficult. Moreover, he illustrates that data binding in very large applications can result in considerable memory consumption.

MVC - front-end app pattern

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Model–View–Controller (usually known as MVC) is an architectural pattern commonly used for developing user interfaces that divides an application into three interconnected parts. This is done to separate internal representations of information from the ways information is presented to and accepted from the user.^[1][2] The MVC design pattern decouples these major components allowing for code reuse and parallel development.

Traditionally used for desktop graphical user interfaces (GUIs), this architecture has become popular for designing web applications.^[3] Popular programming languages like JavaScript, Python, Ruby, PHP, Java, and C# have MVC frameworks that are used in web application development straight out of the box.

Model The central component of the pattern. It is the application's dynamic data structure, independent of the user interface.[4] It directly manages the data, logic and rules of the application.

View Any representation of information such as a chart, diagram or table. Multiple views of the same information are possible, such as a bar chart for management and a tabular view for accountants.

Controller Accepts input and converts it to commands for the model or view.[5]

In addition to dividing the application into these components, the model–view–controller design defines the interactions between them.^[6]

• The model is responsible for managing the data of the application. It receives user input from the controller.
• The view means presentation of the model in a particular format.
• The controller responds to the user input and performs interactions on the data model objects. The controller receives the input, optionally validates it and then passes the input to the model.

Benefits

• High cohesion – MVC enables logical grouping of related actions on a controller together. The views for a specific model are also grouped together.
• Loose coupling – The very nature of the MVC framework is such that there is low coupling among models, views or controllers
• Ease of modification – Because of the separation of responsibilities, future development or modification is easier
• Multiple views for a model – Models can have multiple views

Issues

• learning curve
• too much boilerplate in some frameworks

Potential Value Opportunities

Draw.io Diagrams are free - web based

Potential Challenges

Candidate Solutions

Delivery Team factors impacting goals, organization 

Agile Delivery

https://en.wikipedia.org/wiki/Agile_software_development

Agile Manifesto

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

The Manifesto for Agile Software Development is based on twelve principles:^[22]

1. Customer satisfaction by early and continuous delivery of valuable software.
2. Welcome changing requirements, even in late development.
3. Deliver working software frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

Agile Success Keys

https://www.forbes.com/sites/tracybrower/2019/10/06/is-agile-really-worth-it-evidence-says-yes-if-you-do-these-4-things/#53ff20fe5488

• Focus on people over process
• Embed customers and their feedback in order to continuously improve
• Deconstruct work into small segments and organize effort into short chunks (typically called sprints) in order to get quick feedback and make nimble (agile!) course corrections
• Dedicate people to teams and focus on one project at a time
• Experiment and learn continuously
• Ensure transparency of the work and continuity of the team.

Agile Sprints

1. Sprint plan
   1. epic and story development
   2. backlog review, dependency management and prioritization
   3. planning poker on selected stories
   4. create tickets for stories
2. Sprint
   1. delivery - design, development, test
   2. scrum - daily standups > did, doing, blockers
   3. update tickets on stories, epics
3. Sprint review
   1. review completed and in-progress work
   2. demos
4. Sprint retrospective
   1. lessons learned
   2. improvement opportunities

Sprint Retro session

1. What went well?
2. What didn’t go so well?
3. What have I learned?
4. What still puzzles me?

Agile Pitfalls

Organizations and teams implementing agile software development often face difficulties transitioning from more traditional methods such as waterfall development, such as teams having an agile process forced on them.^[88] These are often termed agile anti-patterns or more commonly agile smells. Below are some common examples:

Lack of overall product design

A goal of agile software development is to focus more on producing working software and less on documentation. This is in contrast to waterfall models where the process is often highly controlled and minor changes to the system require significant revision of supporting documentation. However, this does not justify completely doing without any analysis or design at all. Failure to pay attention to design can cause a team to proceed rapidly at first but then to have significant rework required as they attempt to scale up the system. One of the key features of agile software development is that it is iterative. When done correctly design emerges as the system is developed and commonalities and opportunities for re-use are discovered.^[89]

Adding stories to an iteration in progress

In agile software development, stories (similar to use case descriptions) are typically used to define requirements and an iteration is a short period of time during which the team commits to specific goals.^[90] Adding stories to an iteration in progress is detrimental to a good flow of work. These should be added to the product backlog and prioritized for a subsequent iteration or in rare cases the iteration could be cancelled.^[91]

This does not mean that a story cannot expand. Teams must deal with new information, which may produce additional tasks for a story. If the new information prevents the story from being completed during the iteration, then it should be carried over to a subsequent iteration. However, it should be prioritized against all remaining stories, as the new information may have changed the story's original priority.

Lack of sponsor support

Agile software development is often implemented as a grassroots effort in organizations by software development teams trying to optimize their development processes and ensure consistency in the software development life cycle. By not having sponsor support, teams may face difficulties and resistance from business partners, other development teams and management. Additionally, they may suffer without appropriate funding and resources.^[92] This increases the likelihood of failure.^[93]

Insufficient training

A survey performed by VersionOne found respondents cited insufficient training as the most significant cause for failed agile implementations^[94] Teams have fallen into the trap of assuming the reduced processes of agile software development compared to other methodologies such as waterfall means that there are no actual rules for agile software development.^{[citation needed]}

Product owner role is not properly filled

The product owner is responsible for representing the business in the development activity and is often the most demanding role.^[95]

A common mistake is to have the product owner role filled by someone from the development team. This requires the team to make its own decisions on prioritization without real feedback from the business. They try to solve business issues internally or delay work as they reach outside the team for direction. This often leads to distraction and a breakdown in collaboration.^[96]

Teams are not focused

Agile software development requires teams to meet product commitments, which means they should focus only on work for that product. However, team members who appear to have spare capacity are often expected to take on other work, which makes it difficult for them to help complete the work to which their team had committed.^[97]

Excessive preparation/planning

Teams may fall into the trap of spending too much time preparing or planning. This is a common trap for teams less familiar with agile software development where the teams feel obliged to have a complete understanding and specification of all stories. Teams should be prepared to move forward only with those stories in which they have confidence, then during the iteration continue to discover and prepare work for subsequent iterations (often referred to as backlog refinement or grooming).

Problem-solving in the daily standup

A daily standup should be a focused, timely meeting where all team members disseminate information. If problem-solving occurs, it often can only involve certain team members and potentially is not the best use of the entire team's time. If during the daily standup the team starts diving into problem-solving, it should be set aside until a sub-team can discuss, usually immediately after the standup completes. ^[98]

Assigning tasks

One of the intended benefits of agile software development is to empower the team to make choices, as they are closest to the problem. Additionally, they should make choices as close to implementation as possible, to use more timely information in the decision. If team members are assigned tasks by others or too early in the process, the benefits of localized and timely decision making can be lost.^[99]

Being assigned work also constrains team members into certain roles (for example, team member A must always do the database work), which limits opportunities for cross-training.^[99] Team members themselves can choose to take on tasks that stretch their abilities and provide cross-training opportunities.

Scrum master as a contributor

Another common pitfall is for a scrum master to act as a contributor. While not prohibited by the Scrum methodology, the scrum master needs to ensure they have the capacity to act in the role of scrum master first and not working on development tasks. A scrum master's role is to facilitate the process rather than create the product.^[100]

Having the scrum master also multitasking may result in too many context switches to be productive. Additionally, as a scrum master is responsible for ensuring roadblocks are removed so that the team can make forward progress, the benefit gained by individual tasks moving forward may not outweigh roadblocks that are deferred due to lack of capacity.^[100]

Lack of test automation

Due to the iterative nature of agile development, multiple rounds of testing are often needed. Automated testing helps reduce the impact of repeated unit, integration, and regression tests and frees developers and testers to focus on higher value work.^[101]

Test automation also supports continued refactoring required by iterative software development. Allowing a developer to quickly run tests to confirm refactoring has not modified the functionality of the application may reduce the workload and increase confidence that cleanup efforts have not introduced new defects.

Allowing technical debt to build up

Focusing on delivering new functionality may result in increased technical debt. The team must allow themselves time for defect remediation and refactoring. Technical debt hinders planning abilities by increasing the amount of unscheduled work as production defects distract the team from further progress.^[102]

As the system evolves it is important to refactor as entropy of the system naturally increases.^[103] Over time the lack of constant maintenance causes increasing defects and development costs.^[102]

Attempting to take on too much in an iteration

A common misconception is that agile software development allows continuous change, however an iteration backlog is an agreement of what work can be completed during an iteration.^[104] Having too much work-in-progress (WIP) results in inefficiencies such as context-switching and queueing.^[105] The team must avoid feeling pressured into taking on additional work.^[106]

Fixed time, resources, scope, and quality

Agile software development fixes time (iteration duration), quality, and ideally resources in advance (though maintaining fixed resources may be difficult if developers are often pulled away from tasks to handle production incidents), while the scope remains variable. The customer or product owner often push for a fixed scope for an iteration. However, teams should be reluctant to commit to the locked time, resources and scope (commonly known as the project management triangle). Efforts to add scope to the fixed time and resources of agile software development may result in decreased quality.^[107]

Developer burnout

Due to the focused pace and continuous nature of agile practices, there is a heightened risk of burnout among members of the delivery team.^[108]

Some Agile Terms

Acceptance Test: Confirms that a story is complete by matching a user action scenario with the desired outcome. Acceptance testing is also called beta testing, application testing, and end user testing.

Customer: A customer is a person with an understanding of both the business needs and operational constraints for a project who provides guidance during development.

Domain Model: the application domain responsible for creating a shared language between business and IT.

Iteration: An iteration is a single development cycle, usually measured as one week or two weeks.

Planning Board: Used to track the progress of an agile development project. After iteration planning, stories are written on cards and pinned up in priority order on a planning board.

Planning Game: A planning game is a meeting attended by both IT and business teams that are focused on choosing stories for a release or iteration.

Release: A deployable software package that is a culmination of several iterations of development.

Release Plan: An evolving flowchart that describes which features will be delivered in upcoming releases.

Spike: A story that cannot be estimated until a development team runs a time-boxed investigation.

Stand-up: A daily progress meeting (literally every stands up and meets to keep engaged and motivated), traditionally held within a development area.

Story: A particular business need to be assigned to the software development team. Stories must be broken down into small enough components that they may be delivered in a single development iteration.

Timebox: A defined period of time during which a task must be accomplished.

Velocity: The budget of story units available for planning the next iteration of a development project. Velocity is based on measurements taken during previous iteration cycles.

Wiki: A wiki is a server program that allows users to collaborate in forming the content of a Web site.

SAFE - Scaled Agile Framework

https://drive.google.com/open?id=17IddOUchr7VMAQPkic9VzuMd1BHNS-gC

good ebook

SAFE Diagram

SOC2 principles for operation

https://www.compassitc.com/blog/ssae-16-soc-2-report-the-5-trust-principles

1. Security - The system is protected against unauthorized access, both physical and logical
2. Availability - The system is available for operation and use as committed or agreed
3. Processing Integrity - System processing is complete, accurate, timely, and authorized
4. Confidentiality - Information designated as confidential is protected as committed or agreed
5. Privacy - Personal information is collected, used, retained, disclosed, and destroyed in conformity

Joel 12 Points on Good Software Teams

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

https://drive.google.com/open?id=1FXzSKjiY3kcBL6GEF0uzGsqQgGxhXjpi

12 questions for a good software team

1. do you use source control?
2. can you make a build in 1 step?
3. do you make daily builds?
4. do you have a bug database?
5. do you fix bugs before new code?
6. do you have an up to date schedule?
7. do you have a spec?
8. do programmers have quiet work conditions?
9. do you use the best tools money can buy?
10. do you have testers?
11. do new candidates write code in their interview?
12. do you do hallway usability testing?

writing specs before coding

1. for major user process, create journeys with events
2. for major backend systems, create system flows with events
3. create epics as needed
4. create stories for epics before a sprint ( as a user, given x when y then z so outcomes )
5. create executable test cases for ux ( using jmeter, geb )
6. create executable test cases for services using groovy, postman

Painless Software Schedules

https://www.joelonsoftware.com/2000/03/29/painless-software-schedules/

for a sprint plan, balance resources, features given the time ( 2 weeks )

evidence based scheduling

https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/

Why won’t developers make schedules? Two reasons. One: it’s a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it’s not going to be right?

same as Jim Mason's historical schedule adjustment method

Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date.

work breakdown for tasks

1. You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours.
2. Keep track of how long you spend working on each task.
3. The common estimator has a lot of velocities that are pretty close to each other, for example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}. When you divide by these velocities you increase the amount of time something takes, so in one iteration, an 8-hour task might 13 hours; in another it might take 15 hours
4. updates moscow priorities - actively manage projects to ship on time. For example, if you sort features out into different priorities, it’s easy to see how much it would help the schedule if you could cut the lower priority features.
5. planning poker in sprint plan sessions

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles