May 092013
 

If you’ve ever had any involvement with an Agile project (whether it was “pure” Agile or not), you’ll likely have encountered the beast which is effort forecasting and analysis.  This drives the initial estimate of the amount of work which your team thinks it can deliver within a given period.

Agile sprint
Example of a scrum style sprint
[source]

It doesn’t really matter how big your project is, sizing up the amount of work which can be produced is a time honoured tradition, but how do you know if you’re even in the ballpark of getting your estimates right?

Over at ThoughtWorks Studios, Martin Fowler (and others) have spent significant time and effort in trying to document some conclusions about this very topic and a PDF white paper can be found on the ThoughtWords Studios website.

It’s hardly a light read – at 32 pages – but can you really afford to take estimation lightly?  In a world of commercial agreements, balancing customer or client expectations and attempting to meet tight delivery timelines, getting your estimations accurate is a key step in delivery.

However, in my mind going into this document, it really helps to have a decent view of what it is you are trying to build.  The more uncertainty going into any kind of sizing or storyboarding exercise, the rougher the estimation or analysis is going to be. 

There’s no silver bullet, one-size-fits-all methodology at play here, however this document is a really good read if you are looking to canvass different views and opinions about how to set expectations around Agile delivery.  Be prepared to have your designs challenged, and to field changes as they can (and do) present themselves!

If you aren’t quite ready to dip into the minefield which is Agile planning and forecasting, perhaps you’d find value in another e-book from ThoughtWorks – “How do you develop a shared understanding on an Agile project?”.  Remember, for an Agile project to succeed, everyone needs to play their part – the methodology isn’t just for programmers!

For those who haven’t already gone to visit the ThoughtWorks website, here’s a direct link to the PDF.

Further reading:

Feb 122013
 

To some an ‘Agile’ project means delivering value to a client or business more frequently than with other methodologies.  This can be achieved, with the right people, the right sponsorship within the right organisation which is open to the concept.

Other times, trying to run a successful Agile project will look a lot more like this clip below from YouTube

Unfortunately, this clip likely is a better representation of reality than we’d care to admit.

Without the appropriate buy-in from all stakeholders in a project, and acknowledgement that the Agile approach doesn’t necessarily align with more stringent or rigid processes and frameworks, an Agile approach simply won’t work.

If you want to know why, perhaps it’s worth reading the Agile Manifesto itself.  Believe it or not, behind all the hype, there’s real method to the principals of the manifesto – many of which fly in the face of more rigid and stringent “quality” measures.

Share this article if you agree….



Celebrating 8 years of technical blog writing

Apr 262012
 

Earlier this month some very useful guidance documentation was published on Codeplex
The topic?  Build and versioning guidance, from Microsoft’s ALM Rangers group.

The guides are broken down into a number of PDF files.  In the main documentation archive (which you can download from Codeplex) are a number of files:

  • Branching and Merging Guide – Cheatsheet Advanced Plan.pdf
  • Branching and Merging Guide – Cheatsheet Basic Branch Plan.pdf
  • Branching and Merging Guide – Cheatsheet Picking a Strategy.pdf
  • Branching and Merging Guide – Cheatsheet Standard Branch Plan.pdf
  • Branching and Merging Guide – Cheatsheet Terminology.pdf
  • Branching and Merging Guide – Illustrations.pdf
  • Branching and Merging Guide – Illustrations.pptx
  • Branching and Merging Guide.pdf

Which, all said, cover a fair amount of material. 
Also packaged are some Hands on Labs which provide a useful set of demonstration examples, and can be used with the Beta version of TFS.

According to the main PDF (Branching and Merging Guide.pdf) the following bullet points describe the new content covered in the beta documentation:

  • The guidance will have some new verbiage and recommendations around some of our existing branching
    plans, as well as add some coverage for new branching plans.
  • This guidance introduces you to local workspace which is a new concept in Team Foundation Server 11.
    Local workspace enables you to continue working even when network access is intermittent or
    unavailable thereby providing increased bandwidth availability and client optimizations. 
  • We provide new guidance around effectively managing shared resources in source control by discussing
    various common scenarios and describing the pros and cons with each approach.  This guide lays a solid
    foundation for implementing sharing for your development efforts in your Team Foundation Server
    environment.  
  • Branching and merging with database projects is discussed in detail. 
  • There is in-depth coverage of merge improvements in Team Foundation Server 11. There has been
    enhancements made to the product that brings a whole set of improvements in the area of merging,
    primarily fewer conflicts that require user interaction when merging, new merge tool for conflict
    resolution in merging, new file comparison tool, baseless merging from the UI, and merging available on
    unshelving. 
  • Different scenarios for baseless merging are discussed in this release of the guidance. Baseless merges are
    not ideal but may be required on occasion.  The Pros and Cons of baseless merging are pointed out with
    coverage on the enhancements made in Visual Studio 11 around baseless merging. You can now perform

There are separate diagrams within the “Branching and Merging Guide – Illustrations.pptx” PowerPoint side deck, enabling ease of access for reuse. 

You might recall, I published my own (similar) version of this diagram here on Sanders Technology not that long ago:

image

 

This diagram is an excellent representation of how to branch and merge for multiple feature sets, keeping the main trunk in synch, as well as the features in release order. 

The diagrams get quite a bit more sophisticated, here is another which illustrates my own rules for dev/branch and patch management:

image

What I quite like about these diagrams is that it underscores how important merging and branching are to a mature development lifecycle.

This model allows parallel development as well as maintenance on the released product.

I won’t go into too much detail – there’s a lot to read – suffice to say that if you have a vested interest in learning or understanding application lifecycle management (be it on Team Foundation Server or an alternative), this isn’t a bad place to start.

The guidance could easily be applied to other source control and lifecycle management tools.

Handy Links:

Download the Team Foundation Server 11 Branching and Merging Guidance
Download the Visual Studio 11 Beta
Download the Team Foundation Server 11 Beta
Download the Team Foundation Server 11 Beta Power Tools