1. COMP8040 – Cloud Application Frameworks Agile Project Management
Project Initiation, Scrum and Agile Project Management Software

2. Introduction A look at how one should kick off a project
A look at user stories
Introduction to Scrum
A demo of agile project management software
(c) Larkin Cunningham

3. Traditional Project Mgt. Issues
Traditional software development projects gather requirements up front
Formal documentation
Assumptions are made
Don’t respond well to change
(c) Larkin Cunningham

4. Project Initiation
Before something like Scrum can kick in, we need to ask the right questions of the right people (stakeholders)
We need to weed out assumptions upfront rather than pay for them later
Assumed Consensus
(c) Larkin Cunningham

5. Project Initiation
Need a mechanism to communicate goals, vision, context of a project
Could be as critical as deciding whether the project goes ahead
(c) Larkin Cunningham

6. Project Initiation Need to ask the tough questions upfront
One mechanism that facilitates project initiation is the Inception Deck
Team goes through a series of 10 slides (e.g. PowerPoint) in a deck and fills in the blanks
Process might take 2 days or 10 days and can handle about 6 months of project planning
Inception deck is a living thing – change as required
(c) Larkin Cunningham

7. Inception Deck
(c) Larkin Cunningham

8. Create an elevator pitch.
Ask why we are here.
This is a quick reminder about why we are here, who our customers are, and why we decided to do this project in the first place.
Create an elevator pitch.
If we had thirty seconds and two sentences to describe our project, what would we say?
Design a product box.
If we were flipping through a magazine and we saw an advertisement for our product or service, what would it say, and, more importantly, would we buy it?
(c) Larkin Cunningham

9. Create a NOT list. Meet your neighbours. Show the solution.
It’s pretty clear what we want to do on this project. Let’s be even clearer and show what we are not doing.
Meet your neighbours.
Our project community is always bigger than we think. Why don’t we invite them over for coffee and introduce ourselves?
Show the solution.
Let’s draw the high-level blueprints of the technical architecture to make sure we are all thinking of the same thing.
(c) Larkin Cunningham

10. Ask what keeps us up at night.
Some of the things that happen on projects are downright scary. But talking about them, and what we can do to avoid them, can make them less scary.
Size it up.
Is this thing a three-, six-, or nine-month project?
Be clear on what’s going to give.
Projects have levers like time, scope, budget, and quality. What’s most and least important for this project at this time?
(c) Larkin Cunningham

11. Show what it’s going to take.
How long is it going to take? How much will it cost? And what kind of team are we going to need to pull this off?
(c) Larkin Cunningham

12. Why we are here
(c) Larkin Cunningham

13. Elevator Pitch Template from Geoffrey Moore’s Crossing the Chasm
(c) Larkin Cunningham

14. Elevator Pitch
(c) Larkin Cunningham

15. Product Box
(c) Larkin Cunningham

16. NOT List
(c) Larkin Cunningham

17. The Neighbours
Remember the DevOps philosophy of breaking down the walls of confusion?
(c) Larkin Cunningham

18. Show Your Solution
(c) Larkin Cunningham

19. Keeping Us Up At Night
(c) Larkin Cunningham

20. Rough Timeline
(c) Larkin Cunningham

21. Trade-offs
No two sliders can occupy the same slot Blues are tangibles, whites are intangibles
(c) Larkin Cunningham

22. What it will take
(c) Larkin Cunningham

23. Traditional Requirements Gathering
Some fun cartoons….
(c) Larkin Cunningham

24. Traditional Requirements Gathering
(c) Larkin Cunningham

25. Traditional Requirements Gathering
(c) Larkin Cunningham

26. Traditional Requirements Gathering
(c) Larkin Cunningham

27. Agile Principles Another one from the agile manifesto:
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
How many times have you or someone else misinterpreted a document, , etc.?
Did you ask for clarification face to face or just carry on?
(c) Larkin Cunningham

28. User Stories
User stories are at the heart of agile software development
They are short descriptions (small enough to fit on an index card)
Goal is not to capture all details
No point in capturing everything upfront
It might change!
We may never even implement the story
(c) Larkin Cunningham

29. Good Story vs Bad Story
Bad Better
(c) Larkin Cunningham

30. User Stories Should be end-to-end Should be independent
Should be testable
Should be small and estimable
(c) Larkin Cunningham

31. Scrum
Stories are the currency of the Scrum approach to agile project management
A story is something that can be “grabbed” by a developer (for example) and developed within a short period of time
Related stories can be grouped into a “theme”
Big stories are called “epics”, but we usually try to not work at the level of an epic, instead breaking down into smaller stories
(c) Larkin Cunningham

32. Scrum Intro to User Stories:
ons/introduction-to-user-stories
Lots of other presentations (video and PPT) at:
ons
We will look at one of them now on Scrum
resentations/Getting-Agile-Scrum-Norwegian- Developers-Conference-2012.pdf [Creative Commons License]
(c) Larkin Cunningham

33. Scrum-based Software
There are several solutions, particularly cloud-based
One very popular one is Atlassian’s JIRA Agile (formerly Jira + Greenhopper)
agile/overview
Can be evaluated for free for 30 days (need to provide credit card upfront, though, and cancel before 30 days)
(c) Larkin Cunningham

34. JIRA Agile Brief demo video:
Tqbo
(c) Larkin Cunningham

35. Next Week We will contrast Scrum with Lean Software Development
We will examine another approach: Kanban
We will wrap up the examinable content with a look (at a high level with some code snippets) at some other frameworks of interest beyond Spring
(c) Larkin Cunningham