Best Practices: Agile SharePoint Development with Scrum Slide Deck
As promised the slide deck from my Agile SharePoint Development with Scrum.
Abstract
Provide an introduction to Agile development using Scrum and discuss how the iterative approach to development helps the customer to get the solution they want. Look at how this approach works when applied to SharePoint projects, how it helps leverage more of the core platform and focuses effort on the biggest value areas. We will look at the challenges this brings to your development team by doing early integration, dealing with upgrades and changes and understand how addressing the hard things early is the right approach. We will also discuss how Scrum gives visibility of the project and brings both good and bad news. How getting customer engagement is the primary challenge and how the flexible approach is often at odds with the way work is contracted.
Agile SharePoint Development with Scrum
The session was spilt into two parts, an introduction to Scrum and a discussion about how this can be applied to SharePoint projects. The audience was a good mix of Developers, Managers, ITPros, and business people with a range of exposure to Agile practices and Scrum. The session provided everyone with an understanding of the terminology and process of doing Scrum. There was a focus on ‘What is done’ and a good discussion around how you architect solutions. For those that attended and anyone else interested I recommend you listen to Scott Hanselman’s podcast with Ken Schwaber where Ken covers these topics. Also looking at the question ‘when do you architect solutions?’ I really like Kens take on how, using the waterfall approach, you have to spend time getting it right upfront. The ability to change later in the process is limited and the costs can be prohibitive. Using agile techniques the architecture will emerge over time, you know that you only have the architecture in place to support the business requirements developed. He poses the question, if you had defined the architecture up front what happens if it is changed mid way through the project? With waterfall there is a lot of unpicking to be done and wasted effort. With agile you don’t have to do the unpicking and the rigours of the process, ensuring things are done, means your code base is easier to change.
Being Agile with SharePoint
Here the focus was on facing the tough challenges early, understanding how to package your solutions, deployments to multiple environments, automation of processes and the eclectic mix of tasks you need to do to deal with the upgrade story. There was a significant synergy with Ben Robb’s session on automated builds using Hyper-V and Robert Bogue’s coverage of the SharePoint Patterns and Practices coverage of upgrading.
I plan to do a screen cast of this session to provide some background to the slides and also the animations that really took me a long time to do.
