WHY PROJECTS ARE BAD FOR CREATING GREAT SOFTWARE products?

24.1.2017 – Tampere University of Technology TIE-13106 Project Work on Pervasive Systems

Olli Pietikäinen (olli.pietikainen@nitor.fi)

OBLIGATORY SALES PITCH about NITOR

24.1.2017 2

LEANDESIGN

Agile transformation

Agile delivery

ConsultingTrainingKey Position fulfillment

DevelopmentTestMaintenance

Concept DesignArchitecture

User ExperiencePrototyping

WHAT IS A PROJECT

24.1.2017 3

Project Definitions

???- Your definition of project

24.1.2017 4

Project Definitions

???- Your definition of project

“A project can be defined as a temporary endeavor undertaken to create a unique product or service. Projects are different from other ongoing operations in an organization, because unlike operations, projects have a definite beginning and an end - they have a limited duration.”- Project Management Institute, PMI

“A Project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case.”- Project management methodology PRINCE2 (PRojects IN Controlled Environments v. 2)

24.1.2017 5

Project is a useful concept wHEN…

- You are really building something that you can wrap up, ship and forget - “Normal work” is not development but operations - You know with relatively high certainty what the end result should be

Sounds like software to you?

24.1.2017 6

PROJECTS CAUSE DYSFUNCTION IN SOFTwaRE

PRODUCT DEVELOPMENT

24.1.2017 7

Dysfunctions

- Scope, budget and dates tend to become fixed - Create illusion of certainty in a complex environment - Prevent learning as the end state is known- Create bias for optimizing locally instead of whole

- Optimize within project instead across all projects within the porfolioand organization

- Large batches make delivery unpredictable - Continuous start-stop of projects- Specialists have multiple projects -> multitasking kills productivity - Good project teams get dismantled at the end of the project to work on

different new projects in new teams - Prevents “double loop learning”

24.1.2017 8

Double loop learning

24.1.2017 9

Single loop learning

Double loop learning

CC Attribution-Share alike 3.0 (Xjent03 https://commons.wikimedia.org/w/index.php?title=User:Xjent03&action=edit&redlink=1)

OK, WISEGUY … WHAT’S THE ALTERNATIVE?

24.1.2017 10

RESOURCES -> TEAMS

- Instead of viewing people as resources that can be allocated 20% there and 40% there, people form stable teams that work together longer with a shared an aim and shared priorities

- Stable teams build around value delivery- Learning and improving how to work together better. Taking responsibility as a team - Conways Law: “organizations which design systems ... are constrained to produce designs

which are copies of the communication of these organizations”

Really a team instead of “group of people”!

24.1.2017 11

<image removed>

PLAN -> FOReCAST

- Instead of planning in detail what’s going to happen and when in great detail, do forecasting

- Short term can be forecasted with high predictability, longer term with lower predictability

- Using probability interval instead of fixed dates or euro amounts

24.1.2017 12

<image removed>

PUSH -> PULL

- Instead of pushing work to development teams and asking to estimate when things will be done, teams pull work from queue to be worked on when they’ve finished the previous features

- Heart of the Lean, both in manufacturing and product development

24.1.2017 13

<image removed>

REquirementS -> EXPERIMENTS

- Scientific mindset - PDCA cycle - Considering the things that we

implement as experiments with hypothesis that we want to validate

- Also closely related to A/B –testing- Faster you go, faster you learn

- Small batch sizes instead of large projects shipped in the end

24.1.2017 14

CC BY 4.0 DiagrambyKarn G.

PROJECTS -> INITIATIVES

Initiative “an introductory step <took the initiative in attempting to settle the issue>”- Merriam Webster dictionary

- Taking the first steps to specific direction- Learning as we go - Constantly re-evaluating if this is something

worth spending time and money in - OK stop working on specific initiative if we learn

that it’s not as valuable as we thought it would be - Instead of fixed mindset about fixed end result

with specific requirements that need to be fulfilled

24.1.2017 15

<image removed, sailing in the fog>

DATES -> COST OF DELAY

- Instead of coming up with some arbitrary date when the work should be ready, focus on Cost of Delay and prioritize work that is most valuable from CoD perspective

- “How much each day costs to our organization when this is not yet ready”

https://vimeo.com/101506552

24.1.2017 16

<image removed>

ARE PROJECTS EVIL?

24.1.2017 17

Are PROJECTS EVIL?

Of course not.But they might not be a suitable concept for thinking about work, especially in software product development.

Words convey meanings and implicit assumptions. Make sure they serve you instead of hindering.

“All models are wrong but some are useful”Statistician George E. P. Box

24.1.2017 18

Thank you!

Want to know more? Read.

24.1.2017 19