VÄLKOMNA TILL VÄST Q Sponsras av

Agenda: 17:00 – Mingel och tjöt – Välkomna! – ”Varför skriver vi dåliga krav?” av Deni Aganovic – obligatoriskt tekniskt strul – ”Kravambassadör” av Peter Hedrén Ca 18:15 – Mingel och förslagslåda 18:45 – ”Kontextuellt drivna krav” av Simon Riddertorp 20:00 – Tack och välkomna åter!

En ideell förening för alla som är intresserade av kravhantering Ge möjlighet för breddat nätverk Skapa forum för erfarenhetsutbyte Bidra till utveckling inom kravhantering Främja föreningens medlemmars kompetensutveckling Finns i Öst, Väst och Syd SARE Väst styrelse: Deni Aganovic, Peter Hedrén, Magnus Willner & Stig Ursing VAD ÄR IDAG?

SARE VÄST Q2 – Onsdag 20/4 – Centralhusets konferenser Vi vill ha med dig på tåget! Arbetsgrupp som anordnar träffar Talare på kommande träffar Styrelsemedlem #SARE-vast Vi välkomnar fler sponsorer VAD ÄR IMORGON?

Sponsor Q1

VARFÖR SKRIVER VI DÅLIGA KRAV?

Hur kunde det gå fel trots att…

Det nya intranätet Glasklar kravspecifikation Exceptionellt erfaret och effektivt utvecklarteam Väldigt engagerad styrgrupp och ledning Resultat: Produkten förkastades av användarna direkt

Det globala processverktyget Glasklar kravspecifikation från varje organ Engagerat och drivet utvecklarteam med enorm bredd En referensgrupp som klev genom eld för framgång Resultat: Flera globala marknader förkastade produkten

Den snabba samarbetsplattformen Glasklar problembeskrivning Erfaret och effektivt utvecklarteam Driven och väldigt kunnig beställare Resultat: Stämningsansökan, flera uppsägningar, enorma förseningar

EGOISM

Det nya intranätet Glasklar kravspecifikation – Men inte förankrad hos slutanvändare Exceptionellt erfaret och effektivt utvecklarteam – utan tillit från kund och tillbakatryckt Väldigt engagerad styrgrupp och ledning – Hölls delvis i skuggan och fick korrekt verklighetsbild

Det globala processverktyget Glasklar kravspecifikation från varje organ – bakåtsträvande och inte samarbetsvilliga Engagerat och drivet utvecklarteam med enorm bredd – låsta av kontrakt och leveranspress från intern organisation En referensgrupp som klev genom eld för framgång – där framgång betydde att deras arbetsuppgifter skulle göras av andra.

Den snabba samarbetsplattformen Glasklar problembeskrivning – men total oförmåga att uttrycka den Erfaret och effektivt utvecklarteam – som enbart ville göra roliga grejer och tjäna snabba pengar och vägrade hjälpa kund med de riktiga problemen Driven och väldigt kunnig beställare - men obefintlig projektorganisation och förståelse för utvecklingsprojekt

VAD SKA VI GÖRA?

Varierande workshops Människan fokuserar som mest i 20 minuter Motivera deltagarna regelbundet med att stimulera deras ego Tillåt inga långa tal och utlägg om ”varför”

Överdrivet tydliga effektmål Effektmålen är objektiva Effektmålen är realistiska Alla inblandade måste förstå ”Varför”

Eliminera ”puckon” och skapa ett team Genialisk föreläsning av Jonas Hermansson om förändringsarbete Skapa en neutral arbetsmiljö Motivera egon till att agera mindre egoistiskt Arbeta enskilt med de som insisterar att fortsätta vara puckon

Summa summarum Egoism är roten till all ondska Minska egoism genom tydligare effektmål och varierande workshops Egon som fortsätter vara egon får inte längre vara med i gänget

Källor Wikipedia – Ethical Egoism ( :49) How stuff works – Why do we make bad choices? ( :30) Extraneous factors in judical decisions Wikipedia - Attention span ( :09)

Agenda: 17:00 – Mingel och tjöt 17:30 – Välkomna! – ”Varför skriver vi dåliga krav?” av Deni Aganovic – obligatoriskt tekniskt strul – ”Kravambassadör” av Peter Hedrén Ca 18:30 – Mingel och förslagslåda 19:00 – ”Kontextuellt drivna krav” av Simon Riddertorp 20:00 – Tack och välkomna åter!

Kravambassadör Peter Hedrén, ADDQ Consulting

The work an unknown good man has done is like a vein of water flowing hidden underground, secretly making the ground green. ― Thomas Carlyle, Philosopher, preso?

Example is the best precept. ― Aesop, Greek Author, 620 BC BC preso?

The words printed here are concepts. You must go through the experiences. ― Saint Augustine, preso?

Bakgrund – Projektexempel – Volvo / BMW / John Deere / … Fabrik - Återförsäljare – Inlandstransporter Spanien - England – Best Practice mellan systerbolag – Sammanslagning konkurrenter – Leveranskvalitet systemleverantörer – Banbrytande implementeringar – … Business Analyst Testledare Kravanalytiker Projektledare Testare Styrgrupper Prioriteringsforum Koordineringsforum Familjeföretag Globala Logistikföretag HQ, RK, LK

kravambassadör erfarenheter visualisera fånga det osagda fröplanterare relationsbyggare neutral och retirera

Cover the canvas at the first go, then work at it until you see nothing more to add. ― Camille Pissarro, Artist, visualisera?

A true photograph need not be explained, nor can it be contained in words. ― Ansel Adams, Photographer, visualisera?

I prefer drawing to talking. Drawing is faster, and leaves less room for lies. ― Le Corbusier, Architect, visualisera?

Art is not what you see, but what you make others see. ― Edgar Degas, Artist, visualisera?

The greatest obstacle to international understanding is the barrier of language. ― Christopher Dawson, Writer, visualisera?

Of all of our inventions for mass communication, pictures still speak the most universally understood language. ― Walt Disney, visualisera?

Unreasonable haste is the direct road to error. ― Moliere, French Playwright, fort och fel?

The details are not the details. They make the design. ― Charles Eames, Designer, fort och fel?

We have two ears and one mouth so that we can listen twice as much as we speak. ― Epictetus, Philosopher, tyst taktik?

It's not what you look at that matters, it's what you see. ― Henry David Thoreau, Author, fånga det osagda?

The good ideas will survive. ― Quentin Tarantino fröplanterare?

Usually, the stuff that's your best idea or work is going to be attacked the most. ― Francis Ford Coppola fröplanterare?

We should not moor a ship with one anchor, or our life with one hope. ― Epictetus, Philosopher, fröplanterare?

A word is dead when it is said, some say. I say it just begins to live that day. ― Emily Dickinson, Poet, fröplanterare?

The successful man will profit from his mistakes and try again in a different way. ― Dale Carnegie, Writer, fröplanterare?

The wildest colts make the best horses. ― Plutarch, Philosopher, relationsbyggare?

In seeking truth you have to get both sides of a story. ― Walter Cronkite, Journalist, relationsbyggare?

I invent nothing, I rediscover. ― Auguste Rodin, Sculptor, neutral?

Every great and deep difficulty bears in itself its own solution. It forces us to change our thinking in order to find it. ― Niels Bohr, Physicist, retirera?

We want a story that starts out with an earthquake and works its way up to a climax. ― Samuel Goldwyn, Producer, retirera?

You see things; and you say 'Why?' But I dream things that never were; and I say ‘Why not?' ― George Bernard Shaw, Dramatist, retirera?

Trust your instinct to the end, though you can render no reason. ― Ralph Waldo Emerson, Poet, retirera?

Patience is the companion of wisdom. ― Saint Augustine, retirera?

skapa ägarskap genom visualisera fånga det osagda fröplanterare relationsbyggare neutral och retirera

The important thing is not to stop questioning. Curiosity has its own reason for existing. ― Albert Einstein Question Everything!

Agenda: 17:00 – Mingel och tjöt 17:30 – Välkomna! – ”Varför skriver vi dåliga krav?” av Deni Aganovic – obligatoriskt tekniskt strul – ”Kravambassadör” av Peter Hedrén Ca 18:30 – Mingel och förslagslåda 19:00 – ”Kontextuellt drivna krav” av Simon Riddertorp 20:00 – Tack och välkomna åter!

Agenda: 17:00 – Mingel och tjöt 17:30 – Välkomna! – ”Varför skriver vi dåliga krav?” av Deni Aganovic – obligatoriskt tekniskt strul – ”Kravambassadör” av Peter Hedrén Ca 18:30 – Mingel och förslagslåda 19:00 – ”Kontextuellt drivna krav” av Simon Riddertorp 20:00 – Tack och välkomna åter!

Hä löns int´ förklar´ för den som int´ begrip.

Context driven requirements

1. Shu Learning “a technique that works” Success is following the technique (and getting a success) Learning limits of the technique Success is shifting from one technique to another Fluid mastery - shifting techniques by moment Unable to describe the techniques involved 2. Ha 3. Ri Clark Terry

Basic principles of context driven requirements The value of any practice or method depends on its context. There are good practices in context, but there are no best practices. People, working together, are the most important part of any project’s context. Projects unfold over time in ways that are often not predictable. Requirements are the “what” when delivered solves the business need. Requirement discovery & engineering is a challenging intellectual process. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right time to effectively develop our products.

Context Constraints Rate of Change Governance Team Distribution Size Criticallity Org culture & Climate Novelty Complexity Value

Constraints Ceremony

Constraints Legacy System Missing documentation Lack of knowledge Complex Dependencies Integrations Technical depth Business Domain Regulatory Contractual Application Domain Techniques and tools Certification procedures Compliance to standards

Rate of Change Defined Process Plan driven Predictive way of working Empirical Process Change driven Adaptive way of working

Process Control Defined Process Empirical Process Known Steps Simple Unknown Innovation Complex Waterfall Agile Lean Start up

Way to go Empirical Process Uncertain or volatile requirements Responsible & motivated team Involved customer Defined Process Fixed requirements Fixed Scope contract Fixed price Relay more on: Documents Process Formality Relay more on: Understanding Discipline Skill

Governance Reporting Steering Transparency Safety implications Security implications? Regulations? Requirement status reports Requirement format Requirement planing Requirement attributes Requirement process Requirement traceability Requirement management

Team Distribution Challenges: Difficult to initiate communication Misunderstanding/miscommunication Dramatically decreased frequency of communication Increased communication cost— time, money, and staff Time difference

Sponsor visits Build cohesive team culture The association among project manager's leadership style, teamwork and project success Li-Ren Yang · Chung-Fah Huang · Kun-Shan Wu. Apr 2011 · International Journal of Project Management Build trust Frequent visits by distributed partners Team Distribution

The association among project manager's leadership style, teamwork and project success Li-Ren Yang · Chung-Fah Huang · Kun-Shan Wu. Apr 2011 · International Journal of Project Management Team Distribution

Size

Alistair Cockburn: Agile Software Development

Number of people involved Communication Load Methodology Size Effectivness per person Size

Criticality Loss of life Loss of Money Loss of discretionary money Loss of comfort More Cermony

The association among project manager's leadership style, teamwork and project success Li-Ren Yang · Chung-Fah Huang · Kun-Shan Wu. Apr 2011 · International Journal of Project Management Complexity

Low Technical Complexity Application re-engíneering Component based Interactive performance High Management Complexity Large Scale Contractual Many stakeholders Higher Technical Complexity High performance Custom unprecedented Architecture re-engineering Lower Management Complexity Small Scale Informal Few stakeholders Increased need for high ”level” of cermony

High Complexity situation Productivity gain Team Communication +50% Team Collaboration + 77% Team Cohesiveness +74%

WORK ORGANIZATIOH: PARADIGMS FOR PROJECT MANAGEMENT AND ORGANIZATION: Larry L. Constantine Group cohesion Flexibility Organizational culture & Climate

Where are high-performance teams found Steve Denning. Most high-performance teams are self-organizing teams Manager-led team Self-managed-team Self-organizing team Self-governing team Organizational culture & Climate

Novelty Simple Fuzzy? Requirement Analyst knowledge Stakeholders domain knowledge Coaching Discovery

Disciplined Learning strategies Learn what should be built: Paper prototyping Ambassador user Early delivery Empty / Manual delivery Correct staffing and learn to work together: Early victory Walking Skeleton Simple first, worst second Learn cost / schedule: Core samples Microcosm Correct mistaken design decisions: Micro-incremental development Spikes Story Splitting Integrate early, integrate often Core samples Microcosm Novelty

The association among project manager's leadership style, teamwork and project success Li-Ren Yang · Chung-Fah Huang · Kun-Shan Wu. Apr 2011 · International Journal of Project Management Complexity

Low Technical Complexity High Management Complexity Higher Technical Complexity Lower Management Complexity Increased need for high ”level” of cermony

Complexity Low Technical Complexity Application re-engíneering Component based Interactive performance High Management Complexity Large Scale Contractual Many stakeholders Higher Technical Complexity High performance Custom unprecedented Architecture re-engineering Lower Management Complexity Small Scale Informal Few stakeholders Increased need for high ”level” of cermony

High Complexity situation Productivity gain Team Communication +50% Team Collaboration + 77% Team Cohesiveness +74%

Value Cost Build business value Pay to learn Are we building the right ting? Can these people build it? Wíll our solution work Do we understand the cost? Knowledge Trim the tail

Less More Extensiv Customer involvment Outsourced development Dev team has considerable domain knowledge COTS solution will be used Precedents are available Req tracebility is needed Team is dispersed Testing will be based on requirements Accurate estimates are needed Requirements details

JIT detailing of requirements Requirements are continuously analyzed and defined throughout the life cycle of a project. Requirements are only analyzed and defined when they are needed for planning or development Requirements are only described at the level of detail required.

Time Effectivness Just In Time Minus Timing

In conclusion Requirements aren´t analysed or defined ntil they are needed Development is allowed to begin with inclompete requirement set Analysis and definition is continous throughout the project Requirements are continuosly refined as the project moves forward Only a small investment is required at the start

Contact Simon Riddertorp AddQ Mail: Mobile:

Questions?

Requirement planing Decide How way of working Decide How to Use req artefacts Decide Which Reports to Use Decide How to Maintain req Decide How to Approve req Decide hove to Manage Changing Requirements Decide how to work with a tool Decide how to staff

Amount of Context Needed Story map Epic Actor goal Story Main scenario Acceptance Criteria Extension conditions User Story Use Case Business Rules UI Prototype Activity Diagram Task Descriptions ER Diagram non-functional requirements Use Case Diagram Extension handling steps

Actor: Clerk. Actor Goal: Place an order. Main scenario: 1. Clerk identifies customer, item and quantity. 2. System accepts and queues the order. Extension conditions 1a. Low credit & Customer is ‘Preferred’: System gives them credit anyway. 1b. Low credit & not ‘Preferred’ customer: Clerk accepts only prepayment. 2a. Low on stock: Customer accepts rain-check: Clerk reduces order to available stock level. Epic: As a Clerk I identify customer, item and quantity So that I can place a customer order. Acceptance Criteria: System accepts and queues the order. User Story: As a clerk I identify a preferred customer whit a low credit So that I can place an order. Acceptance Criteria: -System gives customer credit anyway. -System accepts and queues the order User Story: As a clerk I identify a non preferred customer whit a low credit So that I can place an order. Acceptance Criteria: -Clerk accepts only prepayment. -System accepts and queues the order. User Story: As a Clerk I reduce the order to available stock level when low on stock So that I can place an order. Acceptance Criteria: -Customer accepts rain-check. -System accepts and queues the order

Light Medium Heavy Problem Size Lighter methodologies are better, but have limits Number of People Needed