Matt Ganis has held many lead architectural and managerial roles in IBM over his 20+ year career. He started as a mainframe programmer in White Plains, New York in 1983 and moved into the networking arena where he was a member of the core team responsible for building and deploying the first TCP/IP networks within IBM. He was also responsible for the creation of the first IBM Corporate level firewall to the Internet - which is largely credited with exposing the general population of IBM to the power of the Internet. He is one of the co-architects of the SOCKSv5 protocol (RFC1928), which is incorporated in almost all of the WWW browsers today as well as many TCP/IP Client applications. Matt is currently an STSM within S&D organization and part of the ibm.com site architecture team. His responsibilies include personalization for the ibm.com website, implementation of IBM’s Virtual Branch Office in Second Life and is also the community of practice leader of Agile@IBM, (a community of software developers, testers and technical leads that utilize Agile Development techniques). Matt is also currently an Adjunct Professor of Computer Science and Astronomy at Pace University in Pleasantville New York where he teaches at both the Undergraduate and Graduate level. He holds a B.S. degree in Computer Science and an MBA in Information Systems from Pace University, a Master of Science degree in Astronomy from the University of Western Sydney Australia and a doctorate in Computer Science. He has authored or co-authored over 20 papers in both of his fields of interest ranging from programming techniques/System Administration/TCP/IP networking to topics on Stellar Evolution and Radio Astronomy.
Things are moving too fast. To stay competitive we need to think differently and do our jobs differently.
This is the definition of Agile that I like best. I spend quite a bit of time on this slide emphasizing these points: Iterative and incremental – when we build software, we don’t have a long, detailed plan in front of us. We build it piece-by-piece, breaking down the development cycles into small chunks of time called iterations Highly collaborative – This means that our programmers sit in the same room, the customer (or stakeholder) works side-by-side with the developers, answering questions, providing comments and trying the code as it’s developed Just enough ceremony – in effect this means, we’re going to produce just the artifacts we need to move forward within the short iteration, and nothing more. This flies in the face of IPD that requires large amounts of information/documentation/plans to move from one phase to the next High Quality – Make no mistake, this is not a “hacking” method. This is about producing VERY high quality software – as part of the methodology code should be tested continuously Changing needs – Requirements change, it’s a fact of life, so we deal with it and move forward. There is no major ceremony (Change Request or approval process)
There are many reasons to too for alternatives to our heavy, plan-driven methods of development
XP isn’t rocket science. It takes 12 well known practices and implements them. If you can imagine that there is a degree to which you would implement these, and picture that the degree to which you implement them are on knobs or dials, XP’s approach is to turn the knobs ALL THE WAY up (take them to their extreme). For example, it’s always helpful to have a customer talk to the development team about how certain requirements are to be executed, so obviously frequent emails/conference calls, etc make sense. XP takes this communication to an extreme and suggests that the customer sit WITH the developers (in the same room) and become an active member of the team We’ll discuss these practices in a little more detail…
Just some important terms as we go through this presentation
The agile process starts with some set of requirements (or stories). The development team sets its velocity (or an estimate of how much work they believe they can get done in this iteration). The customer chooses the most important stories to have implemented (understanding open issues/bug from previous iterations) that do not exceed the development team’s stated velocity. Work progresses through the iteration with the customer staying in constant contact with the development team to ensure what gets delivered is what the customer expected. At the end of the iteration, the next release of the project is delivered which will include new features/functions and/or bug fixes. At the end of the iteration (or perhaps several iterations) the team (customer included) get together to look back at how they have been operating and make changes (hopefully for the better) to increase their efficiency.
Starting at the lower left, there are set of Backlog items (call them requirements, stories, small pieces of work – whatever). These are the things to get done. The customer’s add entries into the backlog, and the team (together with the customer) chose a set of items that will be committed and delivered in a 30 day Sprint. Everyday there is a small scrum (or meeting) where the team comes together to ask three questions: What did you do since the last meeting ? What obstacles are in your way ? What do you plan to do before we meet again ? The idea is that the TEAM moves the project forward, identifying problems, or roadblocks that are keeping the team from meeting it’s committed Sprint deadline. At the end of the 30 days, there should be a new set of functionality delivered and demonstrated to the customers, and the whole process repeats
Doing a small amount of each task at the same time rather the traditional waterfall model of sequential tasks allows us to incrementally grow an object
The stories add incremental value to the overall project and allow us to build objects We started with a simple prim to add text to a prim Added the display of notecard content on the Prim And finally use HTTP to keep all the objects in sync
Virtually Agile Astro Sabre (Matt Ganis) http://webpage.pace.edu/mganis IBM, Senior Technical Staff Member Hawthorne, NY - September 20, 2007
Who am I ? My Name is Matt Ganis I lead a group inside IBM called Agile@IBM that consists of developers, testers, architects and project managers interested in pursuing Agile methods Officially I work in the ibm.com organization as part of the site architecture team for the external website. I’m also the lead architect for the ibm.com Virtual Branch Office in Second Life
“Internet Time” “ The Conventional wisdom about competition in the age of the Internet is that the business world has become incredibly fast and unpredictable, and we need to throw out the old rules of the game….. For companies competing in the new information economy, the Internet is forcing managers and employees to experiment, invent, plan, and change their ideas constantly while they try to build complex new products and technologies ” Competing on Internet Time: Lessons from Netscape and it’s battle with Microsoft - Michael Cusumano and David Yoffie
What is Agile 1 Agile is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner with " just enough" ceremony that produces high quality software which meets the changing needs of its stakeholders. 1 http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
Why Agile ? <ul><li>Many clients are struggling with application delivery issues: </li></ul><ul><ul><li>Poor IT relationship with the business </li></ul></ul><ul><ul><li>Track record of poor project delivery </li></ul></ul><ul><ul><li>Inability to deliver on-time, on-budget </li></ul></ul><ul><ul><li>Inability to delivery solutions that meet the needs of the business </li></ul></ul><ul><ul><li>Poor results with offshore delivery, or seek to avoid offshore delivery </li></ul></ul><ul><ul><li>Large project backlog </li></ul></ul><ul><li>Internal and external IBM delivery projects are interested in Agile techniques to help address delivery excellence challenges </li></ul><ul><ul><li>Requirements often are not well-defined </li></ul></ul><ul><ul><li>Speed time to deliver critical business functionality </li></ul></ul><ul><ul><li>Reduce technical risk for first of a kind solutions </li></ul></ul>
Agile Practices <ul><li>Planning Game </li></ul><ul><li>Small Releases </li></ul><ul><li>Simple Design </li></ul><ul><li>Continuous Testing </li></ul><ul><li>Refactoring </li></ul><ul><li>40-hour work week </li></ul><ul><li>Pair Programming </li></ul><ul><li>Collective code ownership </li></ul><ul><li>Continuous Integration </li></ul><ul><li>On-Site customer </li></ul><ul><li>Coding standards </li></ul>XP is extreme in the sense that it takes 12 well-known software development "best practices" to an extreme
Key Agile Terms The stakeholder that is responsible (i.e., has money) and “owns” the requirement Customer Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation. Stories are implemented within iterations Iteration Velocity is a method for measuring the rate at which teams consistently deliver business value in a software system (at what rate can they deliver stories) Velocity A project conducted under an Agile Method is broken up into a set of very small deliverables called stories. Stories Definition Term
What makes a “good” story (from Bill Wake: http://www.xp123.com/xplor/xp0308/index.shtml) I N V E S T Testable. Stories need to be testable, otherwise how do you know the story is complete? T Small. Having small stories is a result of estimable and negotiable. The larger the story the harder it is to estimate, the less flexibility in negotiation. S Estimate. If a story can't be estimated (how long to complete) then the customer can't derive value or assign a priority to it. E Value . Stories need to have real business value to the stakeholders so they can chose the most important” ones V Negotiable - Remember that agile methods are typically variable in scope. That is the time line is fixed (iteration length) and the quality and scope are varied. N Independent . We can build them in any order. This allows us to select stories with the highest value I
Iterative Development Flow Stories Velocity Unfinished Work New Function Bug Fixes New Velocity Refactoring Retrospective Iteration Planning Development Latest Version Release Plan Bugs Customer Interaction Iteration Plan
Second Life Object as stories Objects are perfect examples for Agile stories. They have a value based on the function they include, can be independent and are negotiable Requirements Story(s) tasks tasks
Sequential vs. Agile (incremental) Create Object Build Script Test Deploy Create Object Build Script Test Deploy Time
Story Examples <ul><li>The Requirement: </li></ul><ul><ul><li>We want a billboard (that can exist anywhere in Second Life) that will read a list of events from our calendaring system for a given month and display them in an effort to promote attendance. The calendaring system exists inside IBM (behind a firewall) </li></ul></ul>Agile approach <ul><li>Arch </li></ul><ul><li>User Design </li></ul><ul><li>Development </li></ul><ul><li>Customer </li></ul><ul><li>DBA </li></ul><ul><li>Deploy </li></ul>Start Finish <ul><li>Arch </li></ul><ul><li>User Design </li></ul><ul><li>Development </li></ul><ul><li>Customer </li></ul><ul><li>DBA </li></ul><ul><li>Deploy </li></ul><ul><li>Arch </li></ul><ul><li>User Design </li></ul><ul><li>Development </li></ul><ul><li>Customer </li></ul><ul><li>DBA </li></ul><ul><li>Deploy </li></ul>
The Stories (the requirement decomposes into at least 3 stories) <ul><li>Create a billboard that can display “text on a prim” (hopefully sentences) </li></ul><ul><li>Read the text from a standard Notecard that can be dropped on the object </li></ul><ul><li>Add HTTP access to the billboard to retrieve a standard text file for all copies of the billboard </li></ul>
Benefits <ul><li>Value is delivered faster </li></ul><ul><ul><li>We can also achieve a certain level of cost avoidance </li></ul></ul><ul><li>Managing rapid change of requirements based on business value </li></ul><ul><li>Developers are learning and training each other </li></ul><ul><ul><li>Stories will get more complex as skills grow </li></ul></ul>