Agile SharePoint Development – Development

So following on from Agile SharePoint Development – Agile lets look at development, yes we will get to Agile SharePoint Development – SharePoint soon but lets keep things general for a while.

This is a very timely post as today I was talking to the managing partner of a law firm about the next phase of their intranet project and he immediately divided the tasks into three basic categories:

• Projects – these give the firm a brand new benefit.
• Enhancements – these take an existing benefit the firm has and make it better.
• Maintenance – this is the general business as usual, day in, day out tasks that complex systems need to keep them running.

Now one of the interesting things about Agile is, and here we refer back to the Agile Manifesto, is that its about development and just development.  So which of the above types of task would it work for?  In the interests of customer collaboration (over contract negotiation) I’m going to use his definitions (which are actually all about which accounting bucket the work goes into) as they make sense to him and also to me.

Projects are definitely development, we start with nothing and there will be a series of releases until finally it’s done.  Classic Waterfall type scenario and absolutely classic Agile scenario.  Agile has many benefits here and is definitely a good choice.

Maintenance is not development in an Agile sense, yes it often includes small bits of development work but the flow is very different.  There is a stream of Business as Usual work, small changes and enhancements and whilst you can build a backlog and use sprints there are few benefits to be got from it as you have in effect a sausage factory as the work piles in constantly, you process it and release it in frequent small packages.  This you want to tackle by a completely different set of processes, LEAN is a very good fit for this using such techniques as a Kanban board and DevOps to do lots of small releases where you don’t get overwhelmed.

Enhancements is a tricky area as its often too small to justify doing Waterfall or Agile and often too big and chunky to handle  with a LEAN approach.  Also if you work directly for the end user on projects rather than developing a product, which most of us seem to do, then its really your lot in life, your bread and butter work, taking something that’s there and tweaking it.  What do you use?  Well applying Agile to the management process rather than the development process, the first layer of ‘meta-Agile’ if you will, ‘responding to change’ is the key.  On a recent project which was really a large set of small and medium enhancements we started with Agile to get a couple of large items out; then switched to LEAN and Kanban to chew through the numerous small enhancements before swapping back to Agile at the end of the project when the very significant branding changes were required which precluded incremental releases to production.

So to sum up this over long blog post:

• Use Agile for when you have discrete ‘chunky’ releases, classic development territory.
• Use LEAN for when you have continuous ‘thin’ releases, classic maintenance territory.
• Apply Agile to the development process and change your methodology as the projects needs change.

Cheers

Sebastian

 

Agile SharePoint Development – Agile

How can we do SharePoint development in an Agile framework?

First we need to understand what agile is, fortunately there is a definitive source for this, and its succinct as well.

http://www.agilemanifesto.org/

Its worth taking a minute to read it and then reading it again on a regular basis.  In fact why not review it at the start of every sprint, or whatever process you use.

Things Agile is:

• About managing change, the manifesto is written in the present indicative tense, its all about development that is in the process of happening now not about managing a theoretical, future, development or a textbook, past, development.
• This includes changes to the way you are implementing Agile.  If something isn’t working then change how your doing it but communicate it clearly to everyone involved.
• About preferences and decisions, it doesn’t say we don’t do documentation it says that given a choice between working software and lots of documentation we’ll ship the software in preference.

Things Agile isn’t:

• Proscriptive, there are no processes that can make you Agile, not even SCRUM, Pair Programming or Sprints.  Use the process and practices you need to help the individuals in the team interact.
• Avoiding management and control, its about using an appropriate method not about letting everyone get on with whatever they want.

Agile arose as a reaction to the Waterfall techniques that are fantastic for managing fixed specification, fixed cost, fixed timescale deliveries for known problems in known environments.  If you are building a bridge you want to use Waterfall.

Software projects are by their very nature almost never in ‘known’ environments, but that is a topic for the next blog post Agile SharePoint Development – Development where I’ll explore the difference between the known and unknown worlds of development and operations.  I do promise we will get to Agile SharePoint Development – SharePoint soon.

Finally in talking with Gina she proffered this pithy explanation:

With waterfall you get what you asked for not necessarily what you need.

With Agile you get what you need not necessarily what you asked for.

Cheers

Sebastian

SharePoint 2016 – An Introduction

So its released and the question is what doe sit bring to the table?

First off useful links to general start points:

• For General Information: http://sharepoint.microsoft.com
• For Technical Information: http://technet.microsoft.com/sharepoint/fp142366
• For IT Professionals: https://technet.microsoft.com/en-us/library/cc261970.aspx