agile protoyping in academia
DESCRIPTION
TRANSCRIPT
Agile Prototyping in Academia
David F. FlandersJISC Programme Manager, nee Project
ManagerTwitter = dfflanders
So how is this going to work?
Objectives of 30 min talk (2X15min):
1. To introduce the management methodology of Agile Prototyping as fundamental to Academia’s remit to the end user.
2. To go over the Agile Manifesto & its Principles so as to highlight it as a framework of hooks by which real pragmatic human advice can be hung.
3. To demonstrate how the Agile principles (theories) can be turned into working practices (pragmatics) for a small project team (working in Academia) <- according to my previous experience.
* To learn from you on how to do Agile better!
Starter for ten: are we (Unis) in an innovation
recession?
Built technologies for the end user.
AGILE
The Agile Manifesto, c.2001
Origins:• Business sector =
customer/client focused• Middle aged developer
‘hippies’: “Dev is NOT enterprise engineering”.
• S/W should be more intuitive to the human psyche...Web 2.0?
• Manifesto x4 = PinUp Principles x12 = Hooks
The Agile Manifesto:Individuals and interactions
over processes and tools*
Working software over comprehensive documentation*
Customer collaboration
over contract negotiation*
Responding to change
over following a plan*
* = That is, while there is value in the items on the bottom, we value the items on the top more.
Agile Principles...into Practice.
AGILE PRINCIPLES INTO PRACTICES
(1-6) PART I:PRINCIPLES FOR
ORGANISING YOUR USERS
USER-CASESQ: Do you have real users on hand?• User Groups!!!• Über Users• UXer• UserPersonas
(Named) <- user artefacts
• Provide a feedback loop– Feedback button– Phone
No. 2.) Welcome changing requirements, even late in development. Agile harnesses change for the user’s
advantage.STORYBOARDS
Q: What is the setting in which your user lives?
• After user F2F, draw up storyboards to describe user context– Peel situational onion
• Storyboards are modular <- humans change!!!
• Sticky-notes should change as often as users change.
• User is always right: don’t impose your world view!!!
No.3 Deliver working s/w frequently, from a couple of weeks to a couple of months, w/ a preference to the shorter
timescale. WIREFRAMES
Q: Is the psyche of your user on tap (Face2Screen)?
• What is the overall flow of the app from window to window (10K+ft above)– One big window or multiple?– Wizard or tab, etc.
• What does the box & button mean to the user?– On call ÜberUser, UXer– Use Cases + Storyboards =>
Wireframe (CartoonBoxes)
No.4 Continuous attention to technical excellence and good design enhances agility.
PAPER-PROTOYPINGQ: how long does it take
you to produce a version?
• Paper Prototyping is cheaper than writing code.
• Nothing more valuable than putting interfaces in front of users.• Whiteboard projection• Screen-Cast-Crowd-
Sourcing (Drupal)
No.5 Working software is the primary measure of progress.
WORK-PACKAGESQ: Are your WPs
granularly timeboxed?• Consider = could
another dev pick it up and develop it?
• Abandon = How do you recognise FAILs and WINs?
• Adopt = Can your user pick up the s/w and use it without your help?
1-3 weeks total (no more!)
1-3 weeks total (no more!)
No.6 Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
MERITOCRACYQ: How are you talking
about your s/w to others who are using it?
• Agile + Community = Able to do more.
• Agile should enable a team to juggle more work.
• JISC is community.
Pause for discussion.
At this time I would recommend a five minute open discussion take place.
• Comments/questions are anonymous to me so please feel free to be candid.
• Though, if someone could take on the role of scribe to type in the comments to twitter so I have a chance to respond as well?
Otherwise please use this time to turn to your neighbour and ask them what they think thus far.
AGILE PRINCIPLES INTO PRACTICES
(7-12) PART II:PRINCIPLES FOR
ORGANISING YOUR TEAM
No.7 Build projects around motivated individuals. Give them the environ & support they need, & trust them to get
the job done. TEAM-FORMATION
Q: Will the ppl you are working with help or get in the way?
• Get right ppl on the bus and wrong ppl off the bus.
• Team Hierarchy? Google doesn’t have PMs.
• Innovation is achieved by bringing in new talent!
No.8 - The most efficient and effective method of conveying information to & within a development team is
F2F convo.RESOURCING
Q: Where can you find team members you can’t afford?
• Borrow your team from the institution (those who want to innovate)!
• PMing is a group activity. Engage with a community!– How do you
crowdsource?
No.9 The best architectures, requirements, and designs emerge from self-organizing teams.
TEAM-ROLESQ: Do you know thy
team!?• PM / PO• Admin / PM• UXer• Dev (front/back)• Consultants (in the
community) are good.
• Scratch other projects back (barter!)
UXerUXer
DevDev
DevDev
PMPM
POPO
Want Help?Want Help?
SETTINGQ: Where is the stage for
this play?• War room meetings.• Talking Wall
<userVoice>– Artefacts: Storyboard,
Wireframe, Prototypes...
• Point of discussion to keep all engaged.– Users– Team– Stakeholders
No.11 - At regular intervals, the team reflects on how to become more effective, then tunes & adjusts its behaviour
accordingly. SCRUM
Q: How do you enable change to occur?
• Daily “Stand-Ups” (3Xsentences)
• Reflection mtg every 2-3 weeks to review wall artefacts (praxis)
• Priority log of sprints (WPs) to achieve.
• Your project plan should be torn up / amended after the second/third iteration of SCRUM
• Can’t do this w/ >3 x Ppl.
24 hours
version release
2-3 weeks
artefacts
WPs
No.12 Simplicity--the art of maximizing the amount of work not done--is essential.
SPRINTSQ: How do you achieve
small completion wins?
• Chunk work up into achievable WPs– YONWYK
• Achievable = >2 weeks– Set difficulty rating 1-5– If it is a sprint fail, it is a
fail... No “but if...”• Don’t domino WPs
(gaant waterfall bad!) -> burndown charts!?
• Post WINS and FAILS <- you’ll save others/your time!!!
The Agile Manifesto:Individuals and interactions
over processes and tools*
Working software over comprehensive documentation*
Stakeholder collaboration
over remit/contract negotiation*
Responding to change
over following a plan*
* = That is, while there is value in the items on the bottom, we value the items on the top more.
What does Agile and Open development look like?
Man
ag
er
Orie
nte
dM
an
ag
er
Orie
nte
dD
evelo
per
Ori
en
ted
Develo
per
Ori
en
ted
Agile WaterfallCowboy
Summary (Overall)
C O N T I N U U M True agile produces real products for real
people & does it in quick short bursts that are comprehensible to all involved, especially the end
user.
ScrumRefacto
rTDD
Unit Test
XPRAD
6σ
MSPPRINCE
2
RUP
User OrientedUser Oriented
kanbanSCM
Conclusion:
PoP
Thanks
David F. FlandersTwitter = twitter.com/dfflandersBlog = dfflanders.wordpress.com
Open Notebook = code.google.com/p/jiscri
License: Creative Commons Attribution ShareAlike 2.0 UK