SharePoint gives us a great platform for developing sophisticated intranet portals and collaboration sites and many other workloads. But it can also be a challenge to use modern software development frameworks like Scrum and XP. Wouldn’t it be great if we could get all the benefits of Agile practices – faster development, predictable deliveries, better quality, less stress and happy stakeholders? In this session we will cover the definitions of Lean, Agile, Scrum, Kanban, XP, and TDD. Then we will look at the specific challenges around Agile SharePoint development and some development techniques to overcome these obstacles. This talk covers both project delivery and engineering. We’ll look at unit tests, integration tests, UI tests, continuous integration and, of course, test-driven development (TDD) with practical experiences from real-life Agile SharePoint projects.

1. Lean-Agile Development with SharePoint
BILL AYERS

3. Bill Ayers
MCM/MCSM Charter SharePoint
• MCT, MCTS, MCITP, MCSD, MCAD,
MCSA, MCDBA, Professional
Scrum Master (PSM I), etc.
• Flow Simulation Ltd.
• www.SPDoctor.net
• BillA@flosim.com
• @SPDoctor
• Consultant specialising in SharePoint
Development and Architecture for
Web Content Management and
Collaboration and Mobile
Development.

4. Agenda:
• Lean
• Agile
• Kanban
• XP
• Scrum
• TDD
• CI
• Conclusions

5. Pre-historic Software
Development
• FORTRAN/COBOL
• Wish lists
• Ad-hoc development
• No source control!
• Limited tooling
• Computers had lots of spinning
tapes and blinking lights

6. Waterfail
• Big design up-front
• Write-only documentation
• Analysis paralysis
• Wrong product
• Over budget/time
• Project failure
Requirements
Design/Arch
Coding
QA
Deployment
Maintenance

7. Time for Agile

8. Lean
• Manufacturing in 1940s
Japan
• Reduce inventory (work in
progress - WIP)
• Just-in-time
• Counter-intuitive
• Applies just as well to
software development

9. Lean Principles
• Eliminate waste
• Build quality in
• Create knowledge
• Defer commitment
• Deliver fast
• Respect people
• Optimize the whole
• Counter-intuitive

10. Kanban
• Visualizing work
• Making policies explicit (like DoD)
• WIP limits
• Focus on flow (rather than goals)
• Commitment to continuous improvement
• Well suited to reactive processes
• Software optional
9 3
Jeff Lasovski
Used under Creative Commons

11. Agile
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

12. Agile Frameworks
• Kanban (Scrum-ban)
• Scrum
• RUP
• Feature Driven Development
• XP
• Adaptive Software Development
• Crystal
• DSDM Atern

13. Extreme Programming - XP
• Test-first development
• Pair programming
• Refactoring
• Continuous integration
• Frequent releases
• Coding standards
• Sustainable pace

14. What is Scrum?
• Scrum is an agile product development process that allows us to
focus on delivering the highest business value in the shortest time.
• Allows us to rapidly and repeatedly inspect actual working
software (from one to four weeks).
• Business sets priorities. Teams self-organize to determine the best
way to deliver the highest priority features.
• At the end of every sprint, the business can see real working
software and decide to release it as is or continue to enhance it
for another sprint.

15. Scrum
Roles:
• Product Owner
• Scrum Master
• Development Team
Daily Scrum Meeting (15 mins max)
• What I did yesterday
• What I am going to do today
• Impediments
http://www.scrum.org/scrum-guide
• Transparency
• Inspection
• Adaptation
24 hours
Sprint
1-4 weeks
Shippable
Product
Product
Backlog
Sprint
Backlog

16. Scrum Components
Roles:
Product Owner
Scrum Master
The Team
Artefacts:
Product backlog
Sprint backlog
Remaining work
Working software
Definition of Done
Planning board/Charts
Time-boxed Events:
Sprint Planning (1-4h)
Sprint(1-4wk)
Sprint Review (1-4h)
Sprint Retrospective (1-3h)
Daily Scrum (15m)

17. Technical Implications
• To support changing requirements we require flexible emergent
design and architecture
• To support changing design we need to be able to refactor and
this requires automated test coverage, ideally TDD.
• To support demonstration and potential deployment at the end of
each increment we require Continuous Integration.

18. SharePoint is Different
• Need some up-front architecture decisions, certain
types of artefact very difficult to back out once in
production (e.g. list schema)
• Tight integration with the underlying platform can
make code inherently difficult to test
• Platform is a driving factor in the solution design

19. Code Coverage (and other dubious metrics)
Your Custom
Code
SharePoint .NET
SharePoint Unmanaged
Code
ASP.NET
SQL
Windows OS

20. What is TDD?
• Goes beyond Test-first
• Tests drive the low-level design
• Supports refactoring
• Just a developer tool

21. Time for TDD

22. TDD Cycle
write a
failing test
make test
pass
refactor
requirements

23. TDD rulebook
• No code unless failing test
• Write just enough code to pass test
• No new test until green
• Refactoring must not add functionality
• Tests must be fast
• Tests must be easy to run (i.e. automated)
• Purpose of test should be clear
• Tests should be independent (run in any order)
• Test code is a first-class citizen…

24. How does TDD work?
• TDD is counter-intuitive
• Tests facilitate refactoring
• Refactoring facilitates incremental design
• Failing tests pinpoint problems quickly
• Fast (continuous) tests give immediate feedback
• Tests should ideally isolate the code you are working on
• Rapid feedback
• Less bugs

25. Refactoring
• Clean up variable and function names for clarity
• Make code more concise
• Remove spaghetti code
• Remove duplicate code
• Extract methods to avoid oversize methods
• Keep re-running the tests as you re-factor
• If test fails then Ctrl-Z, Ctrl-Z, Ctrl-Z …

26. Shopping List Story

27. Shopping List Story
• As a team site user
• I want my shopping list visible on the home page
• So that I don’t forget stuff
Acceptance Criteria:
• Does a shopping list panel appear on the home page?
• Does the panel show all items in the shopping list?
• Are the items sorted alphabetically

28. DEMO: TDD – INTRODUCTION

29. TDD hints and tips
• Beware excessive use of mocks
• You don’t have to get everything right from the get-go
• Don’t write meaningless tests – e.g. testing library functions,
constructors, language features
• Think of tests as a design tool
• Fake it ‘til you make it
• Tests are like pitons when climbing. You drive in the pitons above
your head as you go – Kent Beck
• Like source control and ALM, TDD is a professional developer’s
tool – don’t dismiss it (Dunning-Kruger effect).

30. Benefits of TDD
• Bugs discovered faster
• Better productivity (once the technique is learned)
• Safe refactoring results in better code design
• Cleaner design because enforces KISS and YAGNI
• Improved code quality and confidence
• Tests document the design
• Easier to handle interruptions to “flow”
• Incremental development
• Guarantees test coverage
• Enables future maintenance and further development by ensuring existing
functionality is maintained (tests)
• Strangely hypnotic, especially if you are listening to progressive dance
music ;-)

31. Drawbacks
• Can be difficult to maintain discipline under pressure
• Difficult in brownfield development
• Difficult without management support
• Excessive and trivial tests
• False sense of security
• Cost of maintaining tests
• Not all development is equally suited to TDD
• Not a silver bullet
• Not appropriate for spikes or other non-production code
• Note all code is easy to test (e.g. SharePoint!)

32. Client-side testing
• The new model – SharePoint-hosted Apps
• Unit testing JavaScript
• Faking the _api
• MVVM data-binding patterns
• Shallow integration (“unigration”) tests

33. Options for client-side
JavaScript testing
• Ad-hoc tests (e.g. console logging)
• QUnit (qunitjs.com)
• TDD style
• Jasmine
• BDD style
• Mocha
• BDD or TDD style
• PYO assertion library
• UI tests (e.g. Selenium, VS UI tests)

34. Running tests
• Can run tests in a browser window
• Chutzpah test runner
• Command line and Visual Studio integration
• Only supports Jasmine and Qunit
• For Continuous Integration use PhantomJS
• Headless browser
• Chrome browser engine (WebKit)
• Phantomjs.org
• Use a cloud test service for “cross-browser test”
• Includes device browsers

35. Using QUnit
• Create a simple web project in Visual Studio
• Tests defined in JavaScript test files
• Test page has div to show results
• Run on any dev. machine - SharePoint not required
module("Test the scoring logic");
app = window.app || {};
test("Score of -100/10 gives appropriate summary", function () {
app.viewModel.numberQuestions = 10;
app.viewModel.currentScore = -100;
equal(app.viewModel.scoreMessage(), "Scoring error...");
});

36. DEMO: CLIENT-SIDE TESTING

37. Continuous Integration (CI)
• PowerShell scripting is the key
• Script everything!
• Strip back to new site collection on each test
deployment
• Rather than building from scratch every time, restore
a base-lined content database first
• Once your project goes live, you need to maintain two
environments – one for test data and one using an
imported live content database

38. Deploying into production
SharePoint
CMS live
environment
Author Approve Publish
Continuous
content
development
process for
artefacts
SharePoint
development
environment Release-based
development process –
Features/Apps
Deploy
Release
Test
Build
Develop

39. CI Hints and Tips
• Build a library of PowerShell functions
• Design your functions so that they can be re-run – detect if data
already exists or delete it
• Use xml file to define configuration properties for each
environment
• Make sure everything is in source control!

40. Conclusions
• Agile continues to gain traction in the development
community as a whole and brings many benefits
• Still many misunderstandings about Agile methods
• Can be a challenge for SharePoint development
because we are building on an existing framework
• Need management and team buy-in to make Agile
work
• Agile methods look simple, but actually quite difficult
to implement effectively
• A good idea to use an Agile coach or get training

41. Recommended Reading:
• www.extremeprogramming.org
• “Clean Code – A Handbook of Agile Software
Craftsmanship”, Robert C Martin
• www.scrum.org – Scrum Guide
• “The Art of Unit Testing”, Roy Osherove
• “Test-Driven Development by Example”, Kent
Beck
• Lean-Agile Acceptance Test-Driven
Development, Ken Pugh

42. questions?
WWW.SPDOCTOR.NET
@SPDOCTOR

43. thank you.
SHAREPOINT AND PROJECT CONFERENCE ADRIATICS
ZAGREB, 10/15/2014 - 10/16/2014