Enough about Process, Let’s Use Patterns

6/2/15

1

Enough About Processes, Lets Use Pa9erns

Paul E. McMahon Principal, PEM Systems

ObjecDves

•  Explain common mistakes

•  MoDvate and explain a be9er approach

•  Share approach with examples

Copyright 2015 PEM Systems 2

6/2/15

2

Background and MoDvaDon


What is SoOware Development?

How can we do be+er helping so3ware prac44oners with the common challenges they face each day?

Reusing Design Pa9erns


…But so3ware development extends far beyond just design and programming

6/2/15

3

Typical SoOware Developer’s Day •  Design 0.5 hour •  Programming 1.0 hour •  Requirements gathering/analysis 0.5 hour •  Customer support 0.5 hour •  EsDmaDng/statusing/improvements 0.5 hour •  TesDng/bug fixing 2.0 hours

•  Admin tasks (email, meeDngs) 3.0 hours


For every 1.5 hours of programming/design, typical developer spends 3.5 hours working other common so>ware development ac?vi?es

1.5 hrs

3.5 hrs

Another QuesDon

•  Are there other pa9erns beyond design and programming – that we haven’t been paying close enough a9enDon to– that could help soOware pracDDoners with the common challenges they face each day?


6/2/15

4

Pa9erns Beyond Design and Programming


Uses pa9erns as aids to get you thinking about how to balance conflicDng ideas

MoDvaDng “Thinking Pa9erns”


Why wouldn’t it make sense to build and deploy the prac?ces we want our developers to follow in small slices?

6/2/15

5

PracDce slice and thinking pa9erns


A prac?ce slice is a common scenario or a small set of related scenarios that a soOware pracDDoner typically faces each day

A thinking paDern is the essenDals of a pracDce slice with key related quesDons, Dps and warnings added in

More MoDvaDon for Thinking Pa9erns


•  PracDces then become a vehicle to help pracDDoners perform be9er

•  What if organizaDons viewed their soOware pracDDoners as their customer for their organizaDonal pracDces?

•  “Study this because it contains how-‐we-‐expect-‐you-‐to-‐operate”

6/2/15

6

What We Have Done in the Past


•  Processes so light they become useless

•  Extremely heavyweight processes

What prac??oners really need falls in between these two extremes

•  Requirements Before Design •  Design Before Code •  Test Before Release

What pracDDoners need to help them perform (two types of informaDon)


•  Basic informa?on about pracDces – How to conduct the pracDce –  Competencies need –  Checklists

•  To be prepared •  CompleDon criteria

TradiDonal processes have done reasonably good job

Where thinking pa9erns can help most

•  Things to watch out for when conduc?ng the pracDce –  Including how to handle common scenarios where difficult decision needed

6/2/15

7

How we discovered “thinking pa9erns”


I don’t know how I can apply these principles in the “fog of war” of

my real project

Pa9ern #1: “I don’t understand a requirement” or “Fly high go fast” •  User story: “As a so9ware developer, I want more guidance in what I should do when I don’t understand a requirement, so that I can build the best so9ware in the least amount of Cme to meet my customer’s needs & my commitments.”


We need simulated missiles that fly high

and go fast!

6/2/15

8

Pa9ern #1: “I don’t understand a requirement” or “Fly high go fast” (cont.) •  Ques?ons to ask: –  Is my customer collaboraDve and working closely with me to discover the requirements?

–  Do I have a fixed schedule and cost?

•  Tips: –  Do nothing different if customer understands cost of iteraDng to discover requirements and is working closely with you

–  Raise a risk if non-‐collaboraDve customer and fixed cost/schedule


Fly high, Go Fast

Pa9ern #2: “My tesDng is taking too long” or “How much is enough?” •  User story: “As a so9ware developer (or tester), I want to know what to do when my tesCng is taking too long, so that I can respond to the pressure from my manager to finish.”


I need to run all these tests to be sure

everything is perfect!

6/2/15

9

Pa9ern #2: “My tesDng is taking too long” or “How much is enough?”(cont.) •  Ques?ons to ask:

–  Does soOware have life-‐criDcal/high cost failure consequences?

–  Does my project have an agreed way of working with respect to tesDng? If so, have I reviewed my tesDng opDons?

•  Tips: –  Consider focusing your low level tesDng just on areas you have changed, if allowed by your agreed way of working.

–  Consider focusing tests on high risk areas, if allowed by your agreed way of working.

•  Warnings: –  Be sure to assess any risk involved in reduced tesDng such as: –  Missing key dependencies. –  Not following the agreed way of working.


Pa9ern #3: “How should I handle a design risk?” or “I’m a new developer” •  User Story: “As a so9ware developer, I want more help in how to handle a design risk, when the alternaCve design is going to extend the schedule, so that I can respond to the pressure to finish on Cme.”


Why don’t you just ask Fred? He’s an expert

in that system.

6/2/15

10

Pa9ern #3: “How should I handle a design risk?” or “I’m a new developer” •  Ques?ons to ask:

–  Have I discussed my design with an experienced coworker or colleague who has implemented a similar design?

–  Have we teamed up new developers with mentors?

•  Tips: –  Call for a peer review. –  Call for a limited peer review with key people focusing just on the design risk, if allowed by your agreed way of working.

•  Warning: –  Less experienced pracDDoners someDmes hesitate asking for help for fear of being perceived as lacking competency


Ask for help

Is training in common pa9erns enough?

•  Does performance improvement always result just from making pracDDoners aware of pa9erns?

•  Also need to recognize pa9erns when faced with a similar situaDon


6/2/15

11

Example: Pa9ern recogniDon from non-‐soOware development domain •  Story about Tom Brady, Quarterback,

New England Patriots, NaDonal Football League –  Brady’s posiDve a9ribute: “decision-‐making”

–  “I don’t know how I know where to pass. There are no firm rules. You just ‘feel’ like you are going to the right place….And that is where I throw it.”


Tom says he doesn’t know how he knows where to pass, but do you know?

Spending hours reviewing videos of next opponent before the game •  Brady spends hours and hours looking at videos of the team he is about to face looking for strengths/ weaknesses of his next opponent


•  Do you think soOware pracDDoners can learn anything from this example?

6/2/15

12

Two sides to our brain •  Quick thinking emoDonal side (System 1)

•  Slow thinking logical side –  (System 2)

•  Quick thinking emo?onal side –  In charge inside most of us and makes most decisions

–  Loves pa9erns


To make beDer decisions, need to recognize “right paDerns,”

But how?

What is Brady doing when he is spending hours watching videos? •  He is preparing (or pracDcing) –  You prepare by thinking ahead of Dme about what you are about to face •  Using slow thinking logical side to refresh the right pa9erns for your fast thinking emoDonal side

•  You know what they are be9er than anyone else!

•  Do you want to become an expert fast? –  Kahneman tells us expert intuiDon is nothing more and nothing less than pa9ern recogniDon and it only comes from sufficient opportunity to pracDce


6/2/15

13

So how might this relate to a soOware pracDDoner’s work day? •  Recall all those other acDviDes beyond design and programming that a soOware pracDDoner typically does each day – Ask yourself: • Which will be most challenging for me today? • What are the pa9erns that will help me respond most effecDvely? • What decisions might I face? • What opDons do I have?


More Sample Scenarios & Guidance to Kick-‐Start Your Pa9ern Development •  With quesDons, Dps and warnings

•  Based on real experiences (“real stories”) that tend to repeat in many organizaDons

•  Includes soOware supporDng roles


6/2/15

14

Pa9ern #4: “How can I help my team improve performance?“ or “Coachable moments”


Should I re-‐start my 2 hour weekly meeDng?

•  User Story: “As a team leader, I want more guidance in what I should do when my team isn’t following the new expected behavior, so that we can benefit from our new improved pracCces.”

Pa9ern #4: QuesDons, Tips, Warnings •  Ques?ons to ask:

–  Have you worked through any conflicts between new agreed way of working and org. policies, culture?

–  If using mulDple coaches, have you agreed on way of working?

•  Tips: –  Consider using a head-‐coach for consistent guidance –  Examples where issues might arise include:

•  Constraints on who can sign up for certain task types •  Capacity planning and risk assessment expectaDons •  ExpectaDons on basis of task esDmates, velocity, burn-‐down charts

–  Watch for “coachable moments”… “Have you considered…”

•  Warnings: –  Keep an eye out for coaches who just coach to their own experiences and are not a9une to needs of your organizaDon


6/2/15

15

Pa9ern #5: “The Non-‐Engaged Stakeholder” or “We need test data!”


We need test data!

•  User Story: “As a sub-‐contract manager, I want more guidance in what I should do when a stakeholder won’t give me the data we need, so that we can meet our schedule and cost commitments.”


Pa9ern #5: QuesDons, Tips, Warnings •  Ques?ons to ask:

–  Have you let your customer know immediately when they are impacDng your performance?

–  Has a stakeholder representaDve been appointed? –  Have they agreed to take on their responsibiliDes?

•  Tips: –  If fixed cost/schedule and impacted, alert customer at once –  OOen stakeholder reps have not been appointed or don’t realize impact –  Second step, dig to see if you can uncover root cause –  Example of possible reasons include:

•  Too much work on their plate •  Lack of communicaDons/understanding of real need •  Poor processes within subcontractor organizaDon •  Lack of authorizaDon

•  Warnings: –  Don’t hesitate to alert customer –  Keep an eye out for stakeholder reps who lack authorizaDon

6/2/15

16

Pa9ern #6: “Why can’t we hit our schedule commitments?” or “That won’t work!”


Our product backlog is never properly prepared!

•  User Story: “As a team lead, I want more guidance in what I should do to help my team, so that we can consistently meet our schedule commitments.”


Pa9ern #6: QuesDons, Tips, Warnings •  Ques?ons to ask: – Are we esDmaDng our future work based on our real recent velocity/performance?

•  Tips: –  Keep personal data on actual Dme spent clarifying backlog items as well as other common soOware acDviDes

– Use actual recent personal data to esDmate

•  Warnings: – OOen teams fail to consider real velocity when predict –  Keep on lookout for “going through the moDons” in retrospecDves, not a9acking the “hard problems”

6/2/15

17

•  Another Tip: –  If the culture in your organizaDon is one where management uses power to pressure pracDDoners to make esDmates they are not comfortable with-‐-‐-‐ •  Keep in mind the story of Korean Airlines in the 1990s –  PotenDal devastaDng effects of inappropriate deference to authority (e.g. “miDgated speech”)


Pa9ern #6: QuesDons, Tips, Warnings (cont.)

A simple way to pilot the thinking pa9ern idea in your organizaDon •  Set up a brainstorming session where you ask parDcipants to

share real stories related to common challenges faced

•  Include at least 1 or 2 experts to sDmulate discussion to understand issues, ask key quesDons, share Dps, and warnings

•  Capture scenario essenDals, key quesDons, Dps, and warnings, prioriDze based on consensus and select small set to train to wider group

•  Provide on-‐the-‐job pa9ern reminder aids and conduct survey to determine if useful


6/2/15

18

Capturing pa9erns on cards as reminder aids


Could add memory jogger reference to “real story”

Reference: “Fly high, go fast”

What makes thinking pa9erns any be9er than checklists?

•  Gives your pracDDoners context

•  SDmulates “criDcal-‐thinking” through the quesDons, Dps, and warnings leading to be9er decisions

•  They are fun to create and stories are great memory aids!


6/2/15

19

How to avoid non-‐value-‐add pa9erns

•  Select only pa9erns – That are common and tend to repeat – Where pracDDoners oOen need help making related decisions

– That present potenDal significant impact to performance

•  Prune pa9erns regularly – When add new pa9erns consider deleDng older pa9erns that are not providing payback


Conclusion

•  Pa9erns don’t replace your company processes, or what your team is doing today

•  They are an aid that can help your team’s criDcal-‐thinking and decision-‐making


6/2/15

20

Contact InformaDon

•  Paul E. McMahon, Principal, PEM Systems •  www.pemsystems.com •  [email protected] •  Phone: 607-‐798-‐7740

39 Copyright 2015 PEM Systems

Enough about Process, Let’s Use Patterns

Software

Transcript of Enough about Process, Let’s Use Patterns