Make better share point stuff with an agile methodology
•Download as PPTX, PDF•
3 likes•1,840 views
Presented at SharePoint Saturday Twin Cities on April 14, 2012 by Doug Hemminger, this is an introduction to Agile methodologies for SharePoint
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
Similar to Make better share point stuff with an agile methodology
Similar to Make better share point stuff with an agile methodology (20)
Recently uploaded
Recently uploaded (20)
Make better share point stuff with an agile methodology
- 1. Make Better SharePoint Stuff with an Agile Methodology Doug Hemminger, SharePoint Saturday, Twin Cities April 14, 2012
- 2. Agenda, about me and what to expect from this presentation INTRODUCTION
- 3. Agenda • What to Expect from this Session • Why Agile • What is Agile • What is Scrum • How to Implement Agile & Scrum
- 4. About Me • Developing since 1997 • Working with SharePoint since 2005 • Assistant Director at Crowe Horwath LLP • Live and work in the Chicago area • Contact me at: • Email: doug@doughemminger.com • Twitter: @DougHemminger • Blog: http://www.sharepointdoug.com
- 5. In This Session, Learn How You Can… • Provide more value to your customers using Agile • Employ Agile & Scrum on your next SharePoint project • Leverage Agile & Scrum tools and resources
- 6. In this section we will explore why you should consider Agile as an appropriate software development methodology for your next SharePoint project. WHY AGILE
- 7. Why Agile • Better • Agile can produce higher quality work • A number of studies demonstrate a lower defect rate and higher customer satisfaction with Agile projects • Faster • Agile projects have a 36% faster time to market • A number of studies demonstrate that features are deployed at a significantly faster rate with an Agile process • Cheaper • Agile projects are roughly 16% more productive and have overall lower costs
- 8. Why Agile • Accelerated time to Happier market Customers • Increased quality • Better team collaboration Happier Employees • Higher productivity State of Agile Development Study: http://www.versionone.com/state_of_agile_development_survey/10
- 9. Salesforce.com – A Case Study • Founded in 1999 • Used traditional software development method – a modified version of the waterfall approach
- 10. Waterfall Wasn’t Working • Time to market was too slow • In 2006 Salesforce.com had 1 major release • Salesforce.com could not respond to customer requests with timely feature releases • Waterfall approach could not easily account for evolving customer needs
- 11. Which Led To… • Unhappy Customers • Low Team Morale • “We had huge morale problems” – Steve Green, Senior Director, Salesforce.com • Productivity declined as the team grew
- 12. There Is A Better Way
- 13. Salesforce.com Implemented Agile • Developed a home-grown version of Agile called the Agile Development Methodology (ADM) • 30 scrum teams, each with 6-10 members • 3 one month sprints made up their first release cycle
- 14. Results Were Immediate… • On average, customers were getting features delivered in half the time • Remember, not a single feature delivered in almost a year: in the first 9 months of using Agile, 60+ features were delivered
- 15. High level definition of Agile and an introduction to the various methodologies. WHAT IS AGILE
- 16. Agile Definition
- 17. Agile Definition • Agile is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self- organizing, cross-functional teams Source: http://en.wikipedia.org/wiki/Agile_software_development
- 18. The 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
- 19. Principles Behind the Agile Manifesto • 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 http://www.agilemanifesto.org/principles.html
- 20. Principles Behind the Agile Manifesto • 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. http://www.agilemanifesto.org/principles.html
- 21. Principles Behind the Agile Manifesto • Continuous attention to technical excellence and good design enhances agility • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. http://www.agilemanifesto.org/principles.html
- 22. Agile Methodologies Source: http://www.versionone.com/state_of_agile_development_survey/10/page3.asp
- 23. High level overview of Scrum WHAT IS SCRUM
- 24. What is Scrum http://www.slideshare.net/sgreene/stanford-7822999
- 25. New Roles with Scrum • ScrumMaster • Owns the process • Removes impediments to the team • Product Manager • Manages the Team, providing vision and boundaries • Makes sure the team works well together • 1 product manager per team
- 26. The Developer Role with Scrum • Collaboration • Become an active participant in understanding product requirements. Can’t sit and wait to be told what to do • Talk to customers and users • Engage coworkers. Help solve problems. Stretch your boundaries. • SharePoint developers on a Scrum project need to be able to step outside their comfort zone and do what is necessary to help out the team. This could include: • Designing • Analyzing • Testing
- 27. SharePoint Developer Technical Skills • Eric White outlines a complete set of SharePoint developer building blocks in a two part series: http://msdn.microsoft.com/en-us/library/gg454784.aspx http://msdn.microsoft.com/en-us/library/gg467340.aspx • Sometimes helpful to separate skills into server-side and client-side
- 28. How to bring Agile to your organization HOW TO IMPLEMENT AGILE
- 29. How to Implement Agile • Get buy-in from management, team members, and most importantly, client and users • Successful adoption of an agile approach does not necessarily just mean selecting an individual method • Do what suits your company’s culture, individual skillsets and talents
- 30. Meetings and Planning • Iteration Planning • Iteration is time boxed – usually 1 to 3 months • Iteration planning can be a single meeting or a series of meetings. Whatever it takes to create and prioritize the product backlog • Prioritizing features and bugs is key • Sprint Planning • Sprint is time boxed – usually 2 to 4 weeks • Sprint planning meeting is 1 to 2 hours depending on the length of the sprint and the size of the team • Creating and prioritizing tasks is key
- 31. Create a Product Backlog • A product backlog consists primarily of: • Features – typically in the form of user stories • Bugs http://www.mountaingoatsoftware.com/scrum/product-backlog
- 32. Create a Sprint Backlog • A sprint backlog consists primarily of developer tasks associated with a feature or a bug http://www.mountaingoatsoftware.com/scrum/sprint-backlog
- 34. Meetings and Planning • Sprint Review • Demo the features completed • Gather feedback • Adjust product backlog (if necessary)
- 35. A brief summary of some available tools AGILE TOOLS
- 36. Agile Tools • Microsoft Visual Studio Scrum 1.0 http://visualstudiogallery.msdn.microsoft.com/59ac03e3-df99-4776-be39-1917cbfc5d8e/ • Microsoft Visual Studio Scrum 1.0 Videos http://blogs.msdn.com/b/aaronbjork/archive/2010/09/09/microsoft-visual-studio-2010-scrum-1- 0-videos.aspx
- 37. Agile Tools • 21 Scrum
- 38. Additional Resources • Mike Cohn • Succeeding with Agile–Software Development Using Scrum • http://www.mountaingoatsoftware.com/ • Ken Schwaber • Agile Software Development with Scrum • http://kenschwaber.wordpress.com/ • Scrum.org • http://www.scrum.org/
Editor's Notes
- Introduction and What to Expect from this SessionI will layout what I hope you will get out of this sessionThis is an interactive session. Please let me know if you have additional expectations or questions along the way.What is AgileDefinitionOverview of the most popular methodologiesDiscussion of the Agile ManifestoWhy AgileWe are going to discuss the general concepts behind the software development process. What must be part of every software development project.Then we are going to analyze a well known case study of Salesforce.com’s transition from traditional software development methodologies to Agile.Then we are going to talk about the benefits of Agile and what you can expect from a successful implementationWhat is ScrumWe are going to discuss the most popular Agile methodology – ScrumHow to Implement AgileWe are going to discuss what is necessary to implement an Agile methodology in your organization.This disucssion will include common pitfalls and ways to get buy-in from leadership and your team
- BetterVersionOne Survey: The State of Agile DevelopmentDr. Dobb’s Journal 2008 Agile Project SurveyMichael Mah (Cutter Consortium)FasterMichael Mah, in a 2008 study comparing 26 Agile Projects to roughly 7,500 traditional projects found that Agile projects have a 36% faster time to marketCheaperMichael Mah, in a 2008 study comparing 26 Agile Projects to roughly 7,500 traditional projects found that Agile projects have are 16% more productive
- Michael Mah, in a 2008 study comparing 26 Agile Projects to roughly 7,500 traditional projects found that:Agile projects have a 36% faster time to marketAgile projects are 16% more productiveCaveat: Developers and business users have to have the ability and desire to collaborate effectivelyVersionOne Survey: The State of Agile DevelopmentDr. Dobb’s Journal 2008 Agile Project SurveyMichael Mah (Cutter Consortium)
- http://www.slideshare.net/sgreene/stanford-7822999http://www.slideshare.net/sgreene/salesforcecom-agile-transformation-agile-2007-conferenceRequirementsLet the meetings begin. For month after month there are hours of meetings each day--meetings with business sponsors, Architects, Analysts, Administrators, and sometimes (occasionally) there are meetings with the users. There is bickering and arguing. Everything is top priority. Everything has to be included. We HAVE to HAVE every feature imaginable. The analysts tell you how the process has to be programmed. The developers say that's a dumb process, "why don't you do it this way" (in the back of their mind, they are thinking how easy it would be to code the process if it were this way). It finally concludes with a 500 printed page document that lands on the System Analysts desk with a thud.DevelopmentThe developers retreat to an undisclosed location. It is said that they are set up in a shanty on Lake Superior in the winter so that they can get food from ice fishing and water from melted ice and never have to leave their computers. But no one knows for sure. Rumor has it that their computers are powered by generators. There is no internet access. They aren't to be distracted from their job of writing code.
- This definition just comes from Wikipedia. It’s a pretty good definition, though. It’s important to understand what some of the terms mean though.IterativeWe are going to be talking about the Salesforce.com case study throughout this presentation. I will introduce it a bit later. But for now, I want to mention the analogy they use in the case study to explain the iterative approach. They describe it like a Train. The train leaves the station at a scheduled time and it is always on time. There are no exceptions. The train leaving the station is your deployment. The passengers getting on the train are your features. Your features pile on to the train while it is in the station, but once it leaves the station at its scheduled time, and it always leaves at its scheduled time, there are no more features allowed to get on the train. This is the essence of an iterative development process. Deployments are scheduled. Features are added in priority order as they are developed. Once it’s time to deploy, the code base is frozen and deployed. Whatever didn’t make it in has to wait to the next deployment.CollaborationCollaboration sounds good, but what does it mean? Even if you have the most detailed requirements in the world, developers will make thousands of decisions throughout the life of the project. We will talk about some of the more traditional approaches later in this presentation, but keep in mind, for now, that one of the purposes of a requirements document in a traditional software development approach is to reduce or eliminate the decision making that a developer has to make. This is becoming increasingly impossible as software development evolves. Why? Because with things like SharePoint and the .Net framework, there are literally millions of lines of code that are already written. You are leveraging those lines of code to create a unique solution and, in so doing, you are choosing to work within a specific framework. Let’s talk about a form as an example. Someone wants you to create a form on SharePoint. They give you a mock-up and give you the basic requirements. The mock-up includes buttons with rounded-corners and special color schemes. Creating a button with rounded corners and a special color scheme can be solved in a variety of ways. But is it even necessary? Rather than make that evaluation yourself, you decide to mock up a simple button without rounded corners but as much of the color scheme as you can easily manage. Then you show it to the user. What do you think. Will this suffice? The user then makes the evaluation. You help them understand the impact of their decision. If there is no cost to the rounded corners and that is what they originally wanted, then of course, that is what they will prefer. But there is a cost. Time. Maybe, with the exception of the rounded corners, the form could be built more easily using a specific platform (maybe InfoPath). But with rounded corners, you are going to have to either do some fancy CSS or use a specific jQuery library. You tell them, if you want rounded corners, it’s going to take longer and we are going to miss the next iteration. I can get it in this iteration if you don’t mind not having rounded corners. This is collaboration.
- VersionOne is a software company that specializes in developing Agile software. They do an annual survey to assess the state of Agile development. The survey is publicly available on their website at http://www.versionone.com. Portions of the survey results will be used throughout this presentation. I have no affiliation with or interest in VersionOne.Who has used an Agile approach to development in your workplace?ScrumXPLean/KanbanFeature Driven Development
- Study in the Global Journal of Engineering Educationhttp://www.scribd.com/doc/65343070/Personality-Types-of-Cuban-Software-DevelopersHuman Interactions in Programminghttp://research.microsoft.com/en-us/groups/hip/
- Eric White (Microsoft)http://msdn.microsoft.com/en-us/library/gg454784.aspx