Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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/

Nick DeNardis

May 08, 2014
Tweet

More Decks by Nick DeNardis

Other Decks in Technology

Transcript

  1. 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
  2. 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
  3. 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?
  4. 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
  5. 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).
  6. 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.
  7. RETROSPECTIVES Start here if you do anything at all Once

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

    so well? 3. What have I learned? 4. What still puzzles me?
  9. INDIVIDUALS AND INTERACTIONS Projects rarely fail because of technology Communication

    (or lack of it) is the root cause of disaster projects
  10. INITIAL EXPECTATIONS Client: This agency is going to make me

    more money Agency: This client is going to pay the bills
  11. COOPERATION Going along with someone else's idea, they have already

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

    off and pipelining means there isn’t a collective knowledge unless you document it
  13. 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
  14. 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.
  15. RELEASES, SPRINTS, ITERATIONS Pick a cycle and stick to it

    If it isn't in the cycle, it isn't important
  16. 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
  17. NO ESTIMATES, ONLY BUDGETS Basecamp just posted a good article

    that sums it up. Drive development with budgets not estimates
  18. 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 "
  19. RECAP agile, not Agile Retrospectives Customer collaboration Working software every

    release Defined release schedule Budgets, not estimates Pairing/swarming
  20. 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