Agile Protoyping in Academia

4,344 views
3,935 views

Published on

Published in: Technology, Business
6 Comments
5 Likes
Statistics
Notes
  • This is intended as an overview of the agile principles and some ways of turning those principles into actual project methods, no one project could do all of these methods and so this is intended as a pick and mix method for how you start to formulate your own agile methodology.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • iwmw2009 p6 - Twitter Search








    For #p6 we used a pre-recorded slidecast... did this work as a format for the session? #iwmw2009
    30 July 2009 11:46
    For #p6 we used a pre-recorded slidecast... did this work as a format for the session? #iwmw2009
    @dfflanders We'll be doing more and more agile development at Kent, but I wonder: is there such a thing as agile maintenance? #iwmw2009 #p6
    29 July 2009 16:21
    @dfflanders We'll be doing more and more agile development at Kent, but I wonder: is there such a thing as agile maintenance? #iwmw2009 #p6
    would rather have everyone talk amongst themselves and take advantage of F2F <-><->2 weeks that get things done quickly #iwmw2009 #p6
    29 July 2009 16:04
    Sprints are quick, achievable work packages for >2 weeks that get things done quickly #iwmw2009 #p6
    Scrum is about binding a team together - daily 3 sentence daily stand up, doing work package in 2-3 then releasing #iwmw2009 #p6
    29 July 2009 16:03
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • comments from twitter:

    scruffian_peej :
    #iwmw2009 The agile model makes 'just do it' more practicable?
    2009-07-30 05:36:53


    MikeNolanLive :
    How can we have flexible teams, allowing people to request a move, when we only have one team of 8 in the first place? #iwmw2009 #iwmwp6
    2009-07-29 10:00:30

    iwmwlive :
    Google does not have PMs and people can move between teams immediately, making sure teams are committed to their task #iwmw2009 #p6
    2009-07-29 09:59:13

    iwmwlive :
    It is important not to impose our own world view on our users - think about their situation in relation to the software #iwmw2009 #p6
    2009-07-29 09:47:58

    iwmwlive :
    Agile welcomes changing requirements, even late in the process. Ask what setting the user lives and storyboard their situation #iwmw2009 #p6
    2009-07-29 09:47:18

    benshowers :
    Listening to Dave Flanders virtual talk at #iwmw2009 http://iwmw.ukoln.ac.uk/iwmw2009/talks/flanders/
    2009-07-29 09:27:22
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Please see notes section on each slide for citations. This presentation and all images w/ in the presentation are creative commons images from Flickr which are attributed via the flickr user name. Many thanks to all those you post pictures with creative commons licenses, it makes creating presentations so much easier!!!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Agile Manifesto here = http://agilemanifesto.org/
    Agile Principles here = http://agilemanifesto.org/principles.html
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
4,344
On SlideShare
0
From Embeds
0
Number of Embeds
402
Actions
Shares
0
Downloads
38
Comments
6
Likes
5
Embeds 0
No embeds

No notes for slide
  • The “Slidecast” Presentation will play on the left side of the screen and the twitter “chat room” will take place on the right side of the screen. The presenter (me, David F. Flanders) is currently in the Colorado Rocky Mountains on Twitter awaiting fellow twitters to chat to in situ = @dfflanders I’ll be available in real-time for questions throughout the presentation which will take place on the other half of the screen. Please use tag = #IWMW2009 We’ll also take two breaks (half way through the presentation and at the end) where I hope you all will be able to have a candid discussion (as I won’t be there!) &lt;eek&gt; &lt;beNice&gt; ;)
  • recession;: Have we stopped spending the Academic currency of ideas as fast as we used to? Or do times require that ideas are spent faster to achieve innovation? Commonalities these ppl share: Did not finish university Were not supported by the University to push forward their ideas Most significantly, they all build technologies for the individual, Bill Gates, Steve Jobs, Larry Page, Sergey Brin, Mark Zuckerberg NOTES: Innovation recession? &lt;- This thought first occurred to me when I began to look at the various companies out in the world who were changing the world: Microsoft, Google, Apple... I then began to look at the culture of the companies (which has lead me to agile) and thenlia most recently I’ve been looking into the ppl who had instilled the ethos of agile in their companies. Bill Gates, Google Guys and Steve Jobs all ardently believe in the end user as the only Ideas are Academic currency (money) Ideas into action (praxis) is the intellectual equivalent of spending money (trade). To turn an idea into an action requires a degree of risk Risk is best mitigated via ignorance (youth) or disregard for risk (playfulness) To increase innovation (get us out of the intellectual recession we live in) we require a methodology that allows for the faster exchange (praxis) of intellectual currency (ideas) into products (prototypes). “ Change Management” does anything but speed up intellectual idea exchange (it is the anti-pattern to praxis) i.e. assigning budget columns to what change is going to take place during this financial year is NOT innovation. Innovation requires a methodology that can immediately act upon ideas in the now based on real problems and real users. Agile is a methodology that embraces the above set of requirements (though it is not the only one). If we want to get out of the recession we have been in we must once again embrace a methodology that allows us to innovate faster, otherwise we might as well give up the training of our working populace to businesses. The trouble with Universities is that they have stopped trying to innovate, and instead have embraced this horrid thing called change management, which to the best of my knowledge is a way of saying that we will change but we’ll only do so once we have carefully assigned a budget column to change so that we can decide how we will change. Come off it, do you still really think you can plan change in a hypermedia world. The Computer Operating System in the form of Unix has changed turned 40 years of age, and the innovations that the computer has enabled has not only been amazing significant but a algorythmic rate of innovative change. No one (not even More) has been able to predict how this change will occur. There are no rules in the Wild Web and so help us all who want to continue to be innovators it will remain so.
  • For me Agile is the methodology that demands that the user is always kept at the centre of what a team is trying to achieve
  • Quick look at what the manifesto says, but will come back to at the end once we have gone over the principles which is where I think the most value of the manifesto lies. The manifesto is there to just remind you of where your core motivation should be.
  • I’ve organised the principles into two sets of advice (according to how I used to run projects): Users and Team. Principles are a generic set of guidelines that are only valuable if you bind real pragamatic human advice to them. These principles should be treated as guidelines not as commandments, Agile was never intended to be presecriptive. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer&apos;s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • Pictures by (FLIckr User names): Brycej Smannion Test Driven Dev (TDD), Refactoring, Rapid App Development (RAD) Unit Testing, Pair Programming, etc ...More eyes (machine or real) the better.
  •   inel S.Das
  • Cowboy Agile (Cowboy Code D2D decision making User is imaginary Developer lead, (no i) Team just follows Agilefall (Waterfall) Big WPs (Gaant+) Over think the future User is imaginary PM lead, (no i) Team lead
  • People over Process/Policy/Politics
  • http://agileconsortium.blogspot.com/2007/12/nokia-test.html http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
  • Agile Protoyping in Academia

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

    ×