Pro Yearly is on sale from $80 to $50! »

Bringing Agile to Higher Ed Without Scaring Anyone

Bringing Agile to Higher Ed Without Scaring Anyone

Working on the Web in higher education has its unique challenges. Regardless of your team setup, getting client feedback at each stage of a project is inefficient; too much time passes between feedback and design next steps. This type of workflow increases the possibility of mistakes and false expectations of deadlines. Nick will talk about creating an agile workflow in your environment to transform clients into partners on a project. This shift in relationship can have a major impact on the speed, accuracy, and level of work produced. Every team is different and introducing agile practices can lead to resistance. Nick will explore techniques to bring an agile workflow to a team for faster feedback loops and to produce better work.

https://github.com/nickdenardis/agile-workflow
http://mi.highedweb.org/conference-schedule/bringing-agile-to-higher-ed-without-scaring-anyone/

9a168ca8182274f100cc89ea5db64708?s=128

Nick DeNardis

May 08, 2014
Tweet

Transcript

  1. AGILE WORKFLOW BRINGING AGILE TO HIGHER ED WITHOUT SCARING ANYONE

    / Nick DeNardis @nickdenardis
  2. NICK DENARDIS Perpetual minimalist. User experience crafter. Speaker. Realist. Web

    Director at . Library Scientist. Technical Director for . Organizer for and . teacher. @waynestate @TEDxDetroit @hewebMI @RefreshDetroit @GDIdet
  3. AND... NOT A TRAINED AGILIST But I am a practitioner

  4. ONCE UPON A TIME... I gave four people six months

    to reconstruct from the ground up our website 42 individual sites, 4,000+ pages, 250 templates, countless stakeholders
  5. THEY DID IT! And thus begins our journey...

  6. HIGHERED IS BUILT ON PROCESSES Let's embrace that

  7. CONTEXT

  8. THIS TALK IS ABOUT TEAMS 2-10 people, local preferred

  9. MY TEAM != YOUR TEAM Not a step by step

    guide
  10. THIS TALK IS ABOUT WEB SOFTWARE Anything else you take

    away from it is a bonus
  11. "AGENCY" WITH "CLIENTS" Managing a product could be it's own

    talk
  12. AND YOU.. Using any agile practices? Who is using traditional

    waterfall? Who oversees a team? Who is on a team? Who is the whole team?
  13. agile, not Agile Agile is short for "agility"

  14. 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
  15. “To heal the divide between business and development” ~ Kent

    Beck
  16. IMPROVE No process or person is perfect

  17. WHAT'S WRONG WITH WATERFALL? Semantic Diffusion The original ideas, as

    they get passed from person to person get more diffused (more and more fuzzy).
  18. None
  19. DO WE HAVE TO GO ALL IN? Nope. But all

    team buy-in is important Everyone must be willing to try ideas for some time before dismissing them.
  20. THE STARTING POINT

  21. RETROSPECTIVES Start here if you do anything at all Once

    a week, or every other week It's about improving slowly over time
  22. FOUR QUESTIONS 1. What went well? 2. What didn’t go

    so well? 3. What have I learned? 4. What still puzzles me?
  23. REPEAT.

  24. INDIVIDUALS AND INTERACTIONS Projects rarely fail because of technology Communication

    (or lack of it) is the root cause of disaster projects
  25. CLIENT CONTACT Project Manager? Designer? Developer? Writer? ... All of

    them.
  26. CUSTOMER COLLABORATION

  27. INITIAL EXPECTATIONS Client: This agency is going to make me

    more money Agency: This client is going to pay the bills
  28. COLLABORATION VS COOPERATION Introduce feedback loops as early as as

    often as possible.
  29. COOPERATION Going along with someone else's idea, they have already

    figured it out and you're along for the ride.
  30. COLLABORATION Build something together, something new happens. Working then handing

    off and pipelining means there isn’t a collective knowledge unless you document it
  31. Dr. Alistair Cockburn, 2002

  32. COLLABORATIVE DESIGN Define minimum requirements and constraints 15 mins -

    Break out individually and create wireframe sketches 5 mins/person - Individual presentation of wireframe to the group Group critique on individual’s wireframe with feedback focused on clarifying the presenter’s design 15 mins - Break out individually for iteration on their own most well-received wireframe 5 mins/person - Presentation/group critique 30 mins - Sketch a single solution based on wireframes and feedback At the end (2 hours) a single wireframe built by the group is complete
  33. None
  34. None
  35. None
  36. RESPONDING TO CHANGE

  37. SUCCESS What does it look like?

  38. PLANNING UP FRONT success == according to plan

  39. ADAPTIVE PLANNING Plan and execute many times on a project

    (every sprint)
  40. POINT NORTH http://pointnorth.io/

  41. ALIGN AND GUIDE YOUR PROJECT North is a set of

    standards and best practices for developing modern web based properties. Included are standards and best practices for all aspects of a project, from kick off through development. North encourages an agile, content-first, approach to product development and a mobile-first, in-browser, system based approach to design and development.
  42. None
  43. WORKING SOFTWARE

  44. RELEASES, SPRINTS, ITERATIONS Pick a cycle and stick to it

    If it isn't in the cycle, it isn't important
  45. None
  46. None
  47. WALKING SKELETON Tiny implementation that performs end-to-end function.

  48. None
  49. THIN VERTICAL SLICE Layer of the implementation that spans every

    component.
  50. None
  51. created by Daniel Kummer efficient branching using git­flow by Vincent

    Driessen translations: English ­ Castellano ­ Brazilian Portugues ­ 简 体中文 (Simplified Chinese) ­ 日本語 ­ Türkçe ­ 한국어(Korean) ­ Français ­ Italiano Fork m e on GitHub Tweet 365 About git­flow are a set of git extensions to provide high­level repository operations for Vincent Driessen's branching model. more ★ ★ ★ git-flow cheatsheet
  52. CONTINIOUS INTEGRATION/DEPLOYMENT

  53. NO ESTIMATES, ONLY BUDGETS Basecamp just posted a good article

    that sums it up. Drive development with budgets not estimates
  54. None
  55. XP/PAIRING/SWARMING

  56. WHY WASTE THE TIME OF MULTIPLE PEOPLE ON A SINGLE

    TASK?
  57. INCLUDE THE CLIENT? As often as possible.

  58. HAVE YOUR CLIENTS WRITE/SIGN OFF ON ACCEPTANCE TESTS WAT?!?

  59. ACCEPTANCE TESTS A php framework for testing your business expectations.

    Behat
  60. F e a t u r e : N e

    w s I t e m s I n o r d e r t o a n n o u n c e h i g h l i g h t s w e n e e d a p l a c e o n t h e h o m e p a g e A s a u s e r I s h o u l d b e a b l e t o s e e u p d a t e s f r o m t h e d e p a r t m e n t S c e n a r i o : T h e n e w s a r e a o n t h e h o m e p a g e s h o u l d d i s a p p e a r i f t h e r e a r e n o n e w s G i v e n t h e r e a r e n o a c t i v e n e w s i t e m s A n d I a m o n " / " T h e n I s h o u l d n o t s e e " N e w s & A n n o u n c e m e n t s " S c e n a r i o : T h e n e w s a r e a o n t h e h o m e p a g e s h o u l d s h o w a m a x o f f o u r i t e m s G i v e n t h e r e a r e f i v e n e w s a c t i v e n e w s i t e m s A n d I a m o n " / " T h e n I s h o u l d o n l y s e e f o u r i t e m s T h e n I s h o u l d s e e " M o r e n e w s i t e m s "
  61. None
  62. None
  63. None
  64. None
  65. RECAP agile, not Agile Retrospectives Customer collaboration Working software every

    release Defined release schedule Budgets, not estimates Pairing/swarming
  66. MY HOPE There is always room for improvement in your

    process.
  67. RESOURCES Agile Manifesto Point North Drive development with budgets not

    estimates Git Flow Cheatsheet Codeship.io - Continious integration and deployment. Target Process Behat - Behavior driven development This talk on GitHub Follow me on Twitter
  68. THE END BY NICK DENARDIS / @NICKDENARDIS https://github.com/nickdenardis/agile-workflow