Agile Protoyping in Academia
•Download as PPT, PDF•
5 likes•3,550 views
The document introduces Agile Prototyping as a management methodology that is fundamental for academia to serve end users. It discusses the Agile Manifesto and its 12 principles, explaining how the principles can be applied through working practices for small project teams in academia. Examples of how the principles can be implemented include using user cases, storyboards, wireframes, paper prototyping, work packages, team formation practices, and daily stand-up meetings. The overall goal of Agile practices is to produce working software that meets user needs through an iterative process of collaboration, adaptation to change, and focus on delivering value.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Agile Protoyping in Academia
Similar to Agile Protoyping in Academia (20)
More from David F. Flanders
More from David F. Flanders (11)
Recently uploaded
Recently uploaded (20)
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?
- 4. Starter for ten: are we (Unis) in an innovation recession? Built technologies for the end user.
- 5. AGILE
- 9. AGILE PRINCIPLES INTO PRACTICES (1-6) PART I: PRINCIPLES FOR ORGANISING YOUR USERS
- 17. AGILE PRINCIPLES INTO PRACTICES (7-12) PART II: PRINCIPLES FOR ORGANISING YOUR TEAM
- 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
Editor's Notes
- 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!) <eek> <beNice> ;)
- 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? <- 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'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