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

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

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

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

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

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

Inception Deck (c) Larkin Cunningham

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

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

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

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

Why we are here (c) Larkin Cunningham

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

Elevator Pitch (c) Larkin Cunningham

Product Box (c) Larkin Cunningham

NOT List (c) Larkin Cunningham

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

Show Your Solution (c) Larkin Cunningham

Keeping Us Up At Night (c) Larkin Cunningham

Rough Timeline (c) Larkin Cunningham

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

What it will take (c) Larkin Cunningham

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

Traditional Requirements Gathering (c) Larkin Cunningham

Traditional Requirements Gathering (c) Larkin Cunningham

Traditional Requirements Gathering (c) Larkin Cunningham

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, email, etc.? Did you ask for clarification face to face or just carry on? (c) Larkin Cunningham

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

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

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

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

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

Scrum-based Software There are several solutions, particularly cloud-based One very popular one is Atlassian’s JIRA Agile (formerly Jira + Greenhopper) https://www.atlassian.com/software/jira- 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

JIRA Agile Brief demo video: http://www.youtube.com/watch?v=KWiSkH9 Tqbo (c) Larkin Cunningham

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