Scaling Software Agility by Dean Leffingwell

Dean is the former founder and CEO of Requisite Inc, responsible for the Requirements Gathering and Analysis Tool: Requisite Pro. It seems like his vast experience from startup to merging with IBM has touched on a number of key software development issues and he is now consulting very successfully and writing good books!

I picked up Scaling Software Agility at a book store/stall at SPA 2008 as it seemed to have a couple of new things to say, or at least say them in new ways - and I was very pleased with my choice!

I believe there is something for everyone in this book - wether you are new to agile or an experienced practitioner. The book touches on a number of topics and leads you from brief "beginner" chapters through to more interesting ones that are very relevant in today's software development arena - the scaling of agility.

Things that stand out in my memory of this book are the application of valuable software quality and management metrics, and the many strategies that Dean suggests can be used to counter the arguments typical organisational "police" will use to counter the attempt to "go [more] agile" and potentially inadvertently lead to "acceptable failure" or worse, "death march".

Usually corporations do not react to the infiltration of agile practices as they are kept within [small] team perimeters, thereby "flying under the radar". If you have a requirement to scale agile, then by definition you clearly have more people and teams that you are concerned about. There is more visibility and attention from the people who might strategically oppose the changes they do not understand, and/or department(s) or programme(s) it is being attempted in - key strategic people that you never previously even knew existed, nor what their concerns were, are now watching your every move.

http://www.amazon.co.uk: http://www.amazon.com:

Why I recommend Scaling Software Agility:

Reason 1: Part 1 covers the essentials of Agile, Waterfall, XP, RUP, Scrum, Lean Software, DSDM, FDD in 85 pages!

Reason 2: Part 2 follows with more depth about the 7 Agile Practices that work: Agile Component Team, Agile Planning and Tracking, Iterations, Small Frequent Releases, Agile Testing, Continuous Integration, Retrospectives.

Reason 3: The 7 practices Leffingwell recommends for Scaling Agile:
- "Intentional Architecture": Approaches on how to tackle large software systems with Agile Architecture
- "Scalable Lean Requirements": Three simple topics that avoid analysis-paralysis failure mode: vision, roadmap and just-in-time (JIT) elaboration
- "Systems of Systems and the Agile Release Train": how to plan, and deliver, complex software components with interdependencies
- "Managing Highly Distributed Development": It is very difficult, and is a problem all successful software programmes face. Sooner or later the team is too big to fit in 1 room, on 1 floor, of 1 building, of 1 city, of 1 country. Inevitably practices have to be developed that can assist software that is developed by many different people, in different locations
- "Impact on Customers and Operations": How marketing, or product owners, or programme owners, will be convinced that Agile is a good thing for them
- "Changing the Organisation": How to address the arguments and fallacies that the corporate immune system is going to throw around as things become more agile
- "Measuring Business Performance": Real, usable, useful management metrics that can be used to control and manage large scale [agile] software development efforts

Thankyou for reading my recommendations!

Building Scalability and Achieving Performance

This is a short and very useful read on scaling architectures - InfoQ got 3 key architects with backgrounds in Twitter, eBay and Betfair to share their experiences, some approaches they take, and some tool recommendations. Practical advice! Building Scalability and Achieving Performance.

Basics of Web Site Optimisation - Rule 5

This post is mainly aimed at small to medium businesses that are just starting out and are keen to get something going, or have just gone live. I can't tell you how many times I have taught people over the past few years just a handful of strategically important things. So...here goes again, this time in a way that I can now simply refer to. As for my credibility - I would rather not divulge that here, read my Web Site Optimisation Rules and you decide. They are, after all, common sense, and common knowledge....like most things I blog about!


My number 5 rule: Comply with the web standards - html

It is pretty amazing to me that there are many "professional" web site developers that do not know that there is actually a consortium of key organisations behind a set of standards for the technologies and protocols used on the internet. The World Wide Web Consortium (w3c) has created, ratified and published standards for HTML and related protocols for years and years!

For the purposes of web sites, in the past, I standardised web pages on an intermediate/transitional standard (HTML 4.01 Transitional Specification) as web browsers I was testing with (Opera, Internet Explorer, Firefox, Netscape) generally rendered (displayed) the intended result as I designed/implemented or acceptably close to that (or the client's requirement).

While researching this entry, I noticed that the W3C have just released an "Editor's Draft" of the latest specification on 17 July 2008. Check it out at HTML 5. I would not consider standardising on this one just yet though.

So how do you know if your web developer has even attempted to create standards compliant web pages or web site for you? You could do it the hard way - use your browser's functionality to view the HTML source of your web page and look for the "DOCTYPE" tag on the first line, for example:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

But verifying that your page is supposed to be complying with one of the standards is not good enough! The wonderful W3C provide very useful and usable online Quality Assurance tools! Use the HTML Validator - simply enter the page name you would like to validate (your page has to be publicly accessible), and see what results you get back!

Alternatively there is a little program you can run, also via the W3C, that will give the same results. It is freely available, and its name is "tidy" or "HTML tidy". It actually is running behind the scenes of the online W3C HTML Validator link above! You can get information and download details from here.

I recommend, if you are interested (this is not difficult actually), that you get a little training in the subject matter! Again the W3C delivers and you can follow the W3 Schools Online Web Tutorials!

Reasoning:
1. If your web pages comply with the standard, the greater the chance that your site will render as you intend in your visitors' different browsers - an excellent idea!
2. If your web pages comply with the standard, the greater the chance that your site will be scraped by the search engine bots - a very good thing!
3. If your pages are NOT COMPLIANT, your search engine RANKINGS will be NEGATIVELY AFFECTED - a VERY BAD thing!
4. If your pages are NOT COMPLIANT, they will take longer to render in a browser as the browser will do its best to guess at correcting the page and this takes extra processing time - a VERY BAD thing!
5. By complying with the standard, you gain tool and developer freedom should you one day decide to maintain your site in a different tool or by a different developer (no lock-in) - a good thing.

And that is my Rule 5. I will be uploading the others as time allows!