Mainline branching strategy using GitVersion(5 min read)

Many versioning and branching strategies are available. I prefer a simple approach: mainline development using GitVersion for automatic Semantic Versioning.

Branch diagram showing Mainline branching strategy

Continue reading Mainline branching strategy using GitVersion(5 min read)

Waterfall does not exist(10 min read)

I often hear people talk about "waterfall" process software development. But a waterfall process doesn't really exist.

Well, there are software projects that meet the description of waterfall — the post-publication name give to the project structure described in Walter Royce's 1970 paper (old link) as the wrong way to develop software.

But there aren't any published methodologies, processes, books, tutorials, courses, tools, or certifications for waterfall. Because it isn't really a thing you should do.

There are many specific methodologies or processes for software development that are iterative, agile, or product based (Scrum, Unified Process, eXtreme Programming (XP), Crystal, PRINCE2, etc).

But there are no such processes for waterfall. Take a look and search for yourself. If you do find one, let me know, because they don't appear to exist.

See, it looks like a waterfall. Gantt chart created in Project Libre.
Continue reading Waterfall does not exist(10 min read)

Azure CLI vs PowerShell vs ARM vs Bicep(14 min read)

A key component of DevSecOps is infrastructure-as-code, and if you are using Azure there are multiple ways to specify what you want.

Microsoft provides Azure PowerShell, the Azure CLI, as well as both Azure Resource Manager (ARM) and the newer Bicep templates. There are also third party (and cross-cloud) solutions such as Terraform and Pulumi.

In the past I have been leaning towards Azure CLI, as I found ARM templates a bit cumbersome, plus my previous experience with migrations vs desired state for database deployments. With Bicep being promoted as a lighter weight alternative I thought I would compare the Microsoft alternatives.

Having now revisited the options, I still prefer scripting, but think I will switch more to PowerShell, particularly as it makes it easier to follow to the tagging, and naming, guidelines.

My recommendations:

  • For incremental development or changing environments, use Azure PowerShell scripts. They allow easy manipulation of parameters, and a migration/scripted approach can handle changes that a desired state/template approach can not.
    • If you are already heavily invested in an alternative scripting system, e.g. Bash, then Azure CLI would be easier to use.
  • If you have relatively stable infrastructure, such as a preset development environment or sample/demo code, that you want to repeatedly tear down and then recreate the same, then Bicep offers a nicer syntax than raw ARM templates. The deployments are viewable in the Azure portal, but templates do have some limitations compared to scripting.
  • In either case, follow the Azure Cloud Adoption Framework naming guidelines, allowing for unique global resources, as well as the associated tagging guidelines.

Example code is available on Github at https://github.com/sgryphon/azure-deployment-examples

Continue reading Azure CLI vs PowerShell vs ARM vs Bicep(14 min read)

Scaling agile – a look at SAFe(10 min read)

One of the cornerstones of agile methods is delivering value – “working software over comprehensive documentation”, “production or it didn’t happen”.

To achieve this, when decomposing stories it is important to keep them independently valuable. Stories are only really finished when they are usable by the end customer.

To focus on progressing stories to completion, you want to minimise work in progress and you want to use a strict stack rank of work – 1st , 2nd, 3rd, etc. (Rather that general priority such as high/medium/low, where you have 20 high priority stories, none of them finished.)

However a stack rank doesn’t scale – if number 1 project in your stack rank has 100 week long tasks, you can’t assign 100 people to the project and have it done in 1 week.

The solution is the proven strategy of divide-and-conquer. If project number 1 can accommodate 20 people, then you assign it 20 people (and probably need to split that into 2 teams), then project 2 might have 10, project 3 has 15 people, and so on.

This means multiple agile teams, that need to co-ordinate, while keeping the overall organisation agile.

The Scaled Agile Framework for Enterprise (SAFe) has an approach that coordinates multiple teams towards common goals, leaves individual teams enough room to be agile, and manages planning horizons to preserve the ability to respond to change.

First we will take a look at the planning process for teams, and how SAFe scales to multiple teams using Program Increments, then we will look at plans vs roadmaps, and preserving team agility.

Continue reading Scaling agile – a look at SAFe(10 min read)

Estimation worksheet(3 min read)

This is a worksheet I have had for a while for calculating estimates using not a single value, but three values for best case, most likely case, and worse case. The values are combined using the PERT formula, to calculate a total estimate, statistical ranges, and an overall estimate including contingency.

Download the worksheet here:

Continue reading Estimation worksheet(3 min read)

SharePoint Online continuous deployment with IonFar Migration(8 min read)

Install-Package IonFar.SharePoint.Migration

The common stack I am currently using to build SharePoint Online solutions generally consists of the following components:

This stack allows automated deployment of the project against a continuous integration (CI) environment. Simple migration scripts (written in PowerShell) are cumulatively run against the environment, and can be easily promoted to a UAT and then Production environment.

IonFar-Basic-Script
Example migration script

Continue reading SharePoint Online continuous deployment with IonFar Migration(8 min read)

Application Lifecycle Management conference – day 2(3 min read)

.NET 4 - Alex Mackey
 
This is a broad topic to cover in only 1 hour, and what is important will vary depending on what areas you work. Alex did a good job of covering some of the essentials (such as the new runtime and side-by-side deployment) as well as some of the cooler features. Things like co-variance / contra-variance may have gone over the heads of some of the audience, but the presentation as a whole was well done.
 
The actual presentation itself was also very punchy, with good use of images (a bit of humour helps keep things interesting) and hilighting of the important parts of slides. Plenty of good demo code as well.
 
Lessons learned from agile - Richard Banks
 
Some valueable recommendations "from the trenches", although I don't know if the limited number of slides quite worked. I presume the intention was to make it more conversational, but (for me at least) it did seem a bit lacking. The content fit the ALM side of the conference well.
 
Build framework enhancements - Stephen Godbold
 
Continuous integration, or at least daily builds, is a key element / best practice in any modern development practice, and it is good to see the enhancements in this area. There is a good story around extensibility, which the demos showed well, although I do worry whether a workflow based solution is getting too complex (compared to a simple build script.)
 
Still, even the out-of-the-box features seem a big step forward. The presentation also demonstrated some good practices, e.g. unit testing of custom build enhancements.
 
Introducing ALM to SharePoint - Jeremy Thake
 
Having led SharePoint development in the early days of MOSS 2007 the developer experience was pretty much a complete disaster. Ah, the simple joy of being able to hit F5 and debug into a SharePoint component, and on a workstation OS!, or of having a build server deliver a SharePoint deployment package (without third party tools and custom scripts).
 
The improvements may have been lost on those in the audience who hadn't struggled with MOSS before, but the presentation did a good job of relating the experience back to the central theme of ALM. Hopefully it convinced those present that SharePoint was now a more viable option.
 
Agile Database Development - Peter Ward
 
This presentation was a bit of a disappointment. It failed to deliver on some of the promised content (e.g. unit testing of T-SQL was not covered), and, while it did mention integration with TFS and other ALM features, these weren't really shown in the demonstrations.
 
I think demos similar to the Build framework enhancements, showing actual integration with continuous builds, etc would have been better. There was discussion in the talk, but no demo.
 
Windows Phone 7 Development - Dave Glover
 
An interesting presentation to end the conference. The XNA demo suffered from technical problems, which did disrupt the flow, but the presenters managed to carry on regardless and did a decent job. Windows Phone 7 will be an interesting platform to watch, but is obviously a version 1 product (e.g. no plans for cut & paste).
 
The presentation was also quite a different style than others -- a long list of discussion points and links to other content, rather than a set of slides, but I think it worked well for the content.

Australian ALM (Appliction Lifecycle Management) Conference(2 min read)

I spent the day at the inaugural Australian ALM conference today. Here are some impressions from the sessions I attended:
 
VS 2010 launch - Microsoft
 
VS is maturing a lot as a testing platform (automation, bug tracking), and this was featured in both Sam & Tanuj's portions of the launch. The launch event was free, and had a lot more attendees than the later conference portion. Handouts include a neat pack of planning poker cards with Microsoft branding.
 
Keynote - Dr Ivar Jacobsen
 
I've written before about Ivar's comments on Method Needs Theory, and it was great to hear him talk. His recent work on Essential Unified Process is available as a VS 2010 process template, with Use Cases, Use Case Modules, etc. It is a good reminder to hear from one of the earlier pioneers of iterative and other best practices just how long these concepts have been around, and the need to be aware when concepts like agile become overloaded with hype.
 
Personally, I prefer the structure that Use Cases give, compared to 'epics' and 'themes' in the User Stories world, particular the early focus on system boundaries, stakeholders and goals to give meaningful context. Like any other methodology UP (Unified Process) can be easily abused, e.g. hundreds 'use cases' instead of the 10-12 that a typical system should have.
 
VS2010 IDE Enhancements - Alex Mackay
 
A grab-bag of some of the new features in VS, with some quirky examples of extensions. Fairly limited in what you can get through in 1 hour, but plenty of good practical examples. The session was presented well, and the audience seemed to like it a lot.
 
Sketchflow - Mitch Denny
 
In the first half Mitch used an interesting presentation tool, Prezi, that I hadn't seen before. I worked kind of like a mind-map, drilling down into different 'slides' as necessary. The second half had plenty of demos, but it might have worked better with more switching between slides & demos, rather than two separate halfs.
 
I very much like Sketchflow, especially using sketchy styles for prototypes, but I don't know how well it will grab on as a separate tool. Hopefully it will gain traction in the designer community, but the interface is quite different for someone used to a coding tool like VS.
 
Introducing Agile: Microsoft Developer Division - Sam Guckenheimer
 
An old presentation (although I hadn't seen it before), mostly on the use of agile practices to deliver VS 2008. It did seem a bit dated, but had a good chunk of information (but no demos -- nothing really relevant to demo). Definitely more ALM than VS.

A kernel of software engineering practices(1 min read)

Ivar Jacobson has written some recent columns for Dr Dobb's Journal about the similarities between different development methodologies, and specifically the difference between processes and individual practices.

The thread has picked up and gain some momentum through columns by other well known industry figures such as Scott Ambler:

A key part of Ivar's proposal is that what's really important is not so much the overall method but the individual practices.

This is similar to Steve McConnell's analysis,  in Code Complete Second Edition, of the improved defect removal rates of methodologies such as Extreme Programming, which are really just the expected effect of the combined individual practices.

Ivar also talks about a "kernel" of practices -- activity and work patten spaces (groupings) and "alphas" (prototypical deliverables). Without going through the detail of EssUP (Ivar's lightweight method based on this), the kernel consists of the following:

Process Area Activity Spaces
(Things to do)
Alphas
(Things to produce)
Competencies Pattern Spaces
Customer
  • Understand the Need
  • Ensure Stakeholder Satisfaction
  • Accept the System
  • Opportunity
  • Customer Representative
 
Solution
  • Specify the System
  • Shape the System
  • Implement Software
  • Test the System
  • Release the System
  • Specified System
  • Implemented System
  • Executable System
    • Test
  • Analyst
  • Developer
  • Tester
 
Endeavour
  • Establish Project
  • Steer Project
  • Support Team
  • Conclude Project
  • Team
  • Backlog
    • Task
    • Defect
    • Change
  • Project
    • Risk
  • Way of Working
  • Project Lead
  • Collaboration
  • Control
    • Feedback
    • Lifecycle
    • Measurement
    • Planning
  • Organisation

 

Different processes, e.g. EssUP, Scrum, MSF, etc, can then be mapped to this kernel of concepts.