Managing (Innovative) Software Projects Chris Riesbeck Electrical - - PowerPoint PPT Presentation

1

Managing (Innovative) Software Projects

Chris Riesbeck

Electrical Engineering and Computer Science Learning Sciences Center for Technology and Social Behavior Northwestern University

Monday, April 16, 2012

2

Monday, April 16, 2012

3

Feature Presentation: Agile Intervention

Monday, April 16, 2012

Week 1

4

WorkIt!

Your personal trainer

hands-free coaching instant diary 100's of downloadable routines We've got the green light for our WorkIt! app. They love the idea of a personalized audio workout coach and exercise tracker.

Monday, April 16, 2012

Week 1

A phone app to call out the steps... ... a page to manage authors, users, and profiles...

5

OK, let's figure

• ut what we

need to build. We'll need a server, home page, page to define workout routines... OK, here's a

• schedule. Let's

get going!

User admin module Workout entry module User sign up, enter profile Download custom workout Workout Caller Demo! Week 1 Week 2 Week 3 Week 4 Week 5 Week 6

Monday, April 16, 2012

6

It took me 3

• hours. I

uploaded it last night. Where's my new user admin page? Were you working

• n that? I may have

covered it up when I uploaded my code this morning! Where is the new database? It's on my laptop ... that I left on the shuttle

Week 2

Monday, April 16, 2012

7

Lessee...what to do next?

Validate emails Allow 24-hour specials Add drag-and-drop Add logout button Fix transition Add multiple emails Fix typo on who we are Add Facebook linkage Reformat login form Do euros Allow notifications Add sleep mode Fix repeat glitch

Task list Eeny meeny... ...this looks good!

Week 3

Monday, April 16, 2012

8 Fix transition Add multiple emails Fix typo on who we are Add Facebook linkage Reformat login form Do euros Allow notifications Add sleep mode Fix repeat glitch Refactor db schema Add average to stats Add median to stats Only let admins delete Reorganize css files Update stats unit tests Add Safari support Animate intro logo Remove premium link Update Ruby gems Find div-by-0 bug Change to daily logs Validate emails Allow 24-hour specials Add drag-and-drop

Task list What about the Facebook link? Was that on the list? The logo dances now!

Week 3

Monday, April 16, 2012

It's just a

• scratch. I'll be
• ut of traction

in 5 weeks. Project progress report... I did the UI Dale did phone app Kim did the DB Karl did the server code and our project is... ... toast

9

Week 4

Monday, April 16, 2012

10

Can we demo downloading a routine and working out? We present next week! We didn't get that far in the schedule. We didn't get there either. Can we at least demo getting a routine? What can we demo? Signing on!

User admin module Workout entry module User sign up, enter profile Download custom workout Workout Caller Demo! Week 1 Week 2 Week 3 Week 4 Week 5 Week 6

Week 5

Monday, April 16, 2012

11

Suddenly...

Monday, April 16, 2012

12

Well, that was a

• disaster. What a

run of bad luck. We're your Guardian Agiles. Who are those guys? We saw you were having problems. Luck had nothing to do with it– watch!

Monday, April 16, 2012

13

This is classic code chaos. It gets worse and worse until a project collapses.

Monday, April 16, 2012

14

You had too many tasks to keep track of. And no focus

• n what really

mattered.

Monday, April 16, 2012

15

Your bus factor was 1 That's how few people need to get hit by a bus for your project to fail.

Monday, April 16, 2012

16

Here's your biggest problem of all. Your schedule saved the best for last, i.e., never.

Monday, April 16, 2012

17

I guess we have to try harder. Not harder.

• Different. One key

idea–early value– and a few practices can help a lot. You're going to get a chance to do this again. We'll pop in to help. Here we go...

Monday, April 16, 2012

We'll need a server, home page, page to define workout routines... A phone app to call out the steps... ... a page to manage authors, users, and profiles...

Week 1

18

Your value is getting lost in features and code.

Monday, April 16, 2012

Week 1

19

An expert authoring a workout routine. A user doing a routine with the phone calling out the steps. A user finding and downloading a routine that fits her profile. A user entering an exercise goal profile. Start with a different question. Great! Put those scenarios into a release backlog. What are your user scenarios? The ones you must have in your MVP?

Monday, April 16, 2012

Week 1

OK, we've got our

• scenarios. Let's

start coding!

20

Not yet! Is all this doable in the time you have?

Scenarios

expert authors routine user adds profile user downloads routine app calls out routine steps

Monday, April 16, 2012

Week 1

21

We really suck as estimating. Things take 2 to 5 times longer than we think.

Scenarios

expert authors routine user adds profile user downloads routine app calls out routine steps

What do you think, guys? 4 weeks? 6? Don't even try to estimate time! Everyone sucks at it.

Monday, April 16, 2012

Week 1

Then sort the tasks from easiest to hardest.

22

You mean like 2 points for a story that looks twice as hard as the easiest ones? First, break the scenarios down into their major development tasks.

Scenarios

expert authors routine user adds profile user downloads routine app calls out routine steps

Give the easiest 1 point. Give more points to the harder ones. Exactly!

Monday, April 16, 2012

Week 1

23

workout editor logic workout db tables workout editor pages profile update logic profile db tables profile update pages login pages download pages phoneside routine DB text to speech code routine "runner" logic phone app UI

Here are the tasks for authoring.

Scenarios

expert authors routine user adds profile user downloads routine app calls out routine steps

Here are the profile editor tasks. Here are the tasks for downloading. Here are the tasks for calling a workout. Let's put our tasks up on the wall.

Monday, April 16, 2012

Week 1

24

Scenarios

expert authors routine user adds profile user downloads routine app calls out routine steps

workout editor logic workout db tables workout editor pages profile update logic profile db tables profile update pages login pages download pages phoneside routine DB text to speech code phone app UI routine "runner" logic

Now let's sort

Monday, April 16, 2012

Week 1

25

workout editor logic workout db tables workout editor pages profile update logic profile db tables profile update pages download pages login pages phoneside routine DB routine "runner" logic text to speech code phone app UI

Let's assign some numbers.

Scenarios

expert authors routine user adds profile user downloads routine app calls out routine steps

1 2 3 5 8

I've seen Fibonacci numbers recommended.

Monday, April 16, 2012

Week 1

26

Scenarios Tasks

expert authors routine build: routine db (3), editor code (8), editor html pages (5) user adds profile build: user profile db (3), updater code (5), profile update page (3) user downloads routine build: user login page (1), routine download page (3), phone routine db (2) app calls out routine steps build: text-speech code (5), routine tracker (5), phone app UI (5)

OK, that gives us 48 points in our backlog. Let's decide what to do first. ...and a way to author new workout routines... None of these test your core value prop! Well, clearly we need a page to create users...

Monday, April 16, 2012

Week 1

27

A user doing a workout with the phone calling

• ut the steps.

What's the make

• r break scenario?

Then do that first. Don't defer value. Build as if each release might be your last. If it doesn't work, nothing else matters?

Monday, April 16, 2012

Week 1

28

We should be able to get that scenario done in two weeks That's too

• vague. It's

going to slip. OK, let's implement running a workout routine.

Monday, April 16, 2012

Week 1

29

Set hard deadlines. One-week timeboxes work well. Each week is an internal release you can user test.

ZFR Release 1 Release 2 Release 3 Final Release Demo! Week 1 Week 2 Week 3 Week 4 Week 5 Week 6

ZFR: zero feature release (MVP skeleton). All key parts (db, server, app, ...) running and talking to each other.

• nly if needed

Monday, April 16, 2012

Week 1

30

DTSTTCPW! In a week? How can we possibly... DTSTTCPW: Do the simplest thing that could possibly work. Don't build a database editor if a text file will work. Backlog anything not essential for validated learning. Design for

• ne function.

Do you really need user login just now?

Monday, April 16, 2012

Week 1

31

OK, let's get started. I'll do the UI, Kim the DB, ... Don't deal

• ut tasks.

Silos: Separating developers by specialized skills and functionality. And don't silo!

Monday, April 16, 2012

Week 1

32

Gang up on stories. Work together to get

• ne story done before

starting another. This will reduce work in progress, and cross-train to improve your bus factor. Make just one queue, most important stories

• first. Take the next one in

line when you're ready, no matter what it is.

User can upload game game parser user join team avatar list page create team file upload Users can team up

Users can edit avatars

avatar edit page

Story To Do In Process Done Agile Task Board: An project information radiator.

Monday, April 16, 2012

Week 1

33

Everyone, be sure email the team when you're working

• n a file!

I put the web server on my dorm desktop with FTP. Repeat after me Source control Don't manage code manually! At last, time to code!

Monday, April 16, 2012

Week 1

34

Make sure everyone checks

• ut a copy at

least daily. Put everything, code, documentation, sketches, ... in a source control repository. A cloud solution like github works well.

Monday, April 16, 2012

Week 1...

35

2...

Monday, April 16, 2012

Week 2

36

We did it! We had to simplify a lot but it

• works. What a push.

Test what you've built with some real users. Let's start on the next scenario! Not yet. Something way more important. Remember: Build–Measure– Learn. OK -- I can take care of getting this out to our test users.

Monday, April 16, 2012

Week 2

37

OK, some users are using Release 1. What didn't work

• ut so well this

first iteration? Now for the next scenario. Not yet. Reflect first! Why not? What change might help?

Monday, April 16, 2012

Week 2

38

One of us didn't use the source control system. OK, that happens. Why not? What would fix it? "Try harder" is not a good answer. I'm on Windows. I had trouble using git in a command window. I've installed a GUI plug-in which should make it easier for me.

Monday, April 16, 2012

Week 2

39

Now for the next scenario. Not yet. Are you on track to finish? What does your burndown chart predict? OK, we're testing, we've changed some processes...

Monday, April 16, 2012

Week 2

40

We'll need to push harder to make the deadline.

13 25 38 50 #1 #2 #3 #4 #5 48 42 Iteration

Burndown Re-scope! Reduce the number of

• stories. Drop

nice-to-have's. Simplify the must- have's. We started with 48

• points. Now we have 42.

That's not sustainable and will hurt quality. The burndown predicts finishing way too late.

Monday, April 16, 2012

Week 2

41

Let's start coding!

13 25 38 50 #1 #2 #3 #4 #5 48 38 Iteration

Burndown OK, dropping some workout features we don't need, we get 38 points. That should work.

Monday, April 16, 2012

Week 3...

42

4...

Monday, April 16, 2012

43

Remember: early value, user scenarios, timeboxes, source control... that's for starters. Thanks, Guardian Agiles!!! Good luck! We did it. Every week, we picked the next most important scenarios and made it work. Often it wasn't what we originally planned to do at all.

Monday, April 16, 2012

44

What about you? Could you use some Guardian Agiles?

Monday, April 16, 2012

45

Readings

! User Stories Applied. Mike Cohn.

Addison-Wesley, 2004.

! The Agile Samurai. Jonathan Rasmussen. Pragmatic

Bookshelf, 2010.

! Jim Murphy's Agile For Startups slides ! Eric Ries' Startup Lessons Learned blog ! Mike Cohn's Succeeding with Agile blog ! Elisabeth Hendrickson's Agile Acid Test ! Intro to Extreme Programming

Monday, April 16, 2012

Appendix

46 Monday, April 16, 2012

47

The Problem

Monday, April 16, 2012

48

“Schedule Estimation and Uncertainty Surrounding the Cone

• f Uncertainty.” Todd Little. IEEE Software May/June 2006

“An estimate is the most optimistic prediction that has a non-zero probability

• f coming true.” Tom DeMarco,

Controlling Software Projects, Prentice Hall, 1982.

The Problem

Monday, April 16, 2012

Minimum Viable Product

Terms

49

Release ! "that version of a new product

which allows a team to collect the maximum amount of validated learning about customers with the least effort."

! Not a mockup, not just

something small or easy

! A releasable version of the

product

! Need not be public ! A month or so at most

Monday, April 16, 2012

Iteration

Terms

50

Backlog

• A timebox in which the team

commits to the implementation

• f a certain set of user stories.
• Every iteration same duration
• 1 or 2 weeks

! A set of stories to be done ! Release backlog: stories that

define the current release

! Iteration backlog: stories

selected for the current iteration

Monday, April 16, 2012

Create a use case diagram to keep track of the key tasks for every user type.

51

Use this when picking the most important scenarios.

Monday, April 16, 2012

Iteration Overview

At start of each iteration, select next subset to do. Backlog of user stories planned for this release

Diagram from The Software Project Manager's Bridge to Agility Sliger and Broderick

Update backlog stories at any time.

52

Monday, April 16, 2012