Category Archives: working life

Doing Architecture with Agile Teams

Alan Gawthorpe & I a talk last month on doing architecture with agile teams:

We did the session agile-style: We had cards for our topics, and the ‘customers’ in the audience prioritised. I think it worked okay, it would probably go smoother doing it a second time. Some of the significant books & articles that went into the slides were:

Agile Methodologies for the Enterprise

* Scott Ambler & Mark Lines – Disciplined Agile Delivery
* Scott’s whitepaper on [email protected]

What does a technical architecture for agile look like?

* Coplien & Bjørnvig, Lean Architecture for Agile Software Development
* Poppendieck & Poppendieck, Lean Software Development: An Agile Toolkit
* http://alistair.cockburn.us/Walking+skeleton

The further reading list

* George Fairbanks, Just Enough Software Architecture
* The UK government’s national audit office report on Agile Governance
* http://www.disciplinedagiledelivery.com/
* http://en.wikipedia.org/wiki/OpenUP

Basic SEO—An Example

A friend of name, a teenage actor, asked me about SEO stuff earlier today. She has a website and was concerned it wasn’t rising up the rankings very well.
Using a third party website site doesn’t give you a huge amount of control but the basics are the same under any circumstances: You need a page with information on the topic at hand; and you want other websites to link to it. I originally had Rachel’s name in the title of this post, but since she’s now dominating the rankings for here name, I guessed it was no longer necessary! It does help if you have a name like Rachel Kevern though – shared by only a handful of other people in the world 😉

Rachel Kevern

In 2013 I saw Rachel acting & singing in Les Miserables and also saw her singing last night as part of The Voice. Which was excellent! After that, she got the role of Vi, the Reverend’s wife in Footloose, at the Z-arts centre in Manchester. Find her at http://rachelkevernactor.wix.com/rachelkevern.

Agile Adoption

If a team or organisation wants to adopt agile, should they do it all in one, or gradually? How do you overcome problems in agile adoption?

Agile Principles when Adopting Agile

Agile is not about process and methodology; it’s about people, relationships and learning and so turns out to be very much democratic and consensus based. Effective adoption presupposes that you’ve got the team(s) on board; if you have to impose agile, you’re probably doing it wrong. You can’t adopt faster than your teams and individuals are motivated to adopt.

If you apply the agile manifesto to the project of ‘adopt agile’ then you’d adopt agile incrementally, of course. I suggest an obvious principle: You can’t adopt faster than you can learn.

Agile’s take on organisation & adjustment is that teams self-organise with regular reflection, which enables you to see what’s not going well and consider ways to correct. There is no learning without feedback. Adopt incrementally with regular reflection and adjustment.

Agile teams puts work items in priority order, in to deliver the greatest business value first. Look at your current pain points – what’s not working well – and find out which practices are found to address them. Prioritise changes which add most value.

Risk management is arguably a missing subject in agile, so let’s add that here: soberly consider what, at this stage, you are capable of adopting successfully. First adopting practises you’re capable of to maximise your chance of early success. The choice to deliver value or to attack risk first is a judgement call. When you’re doing something new the risk of failure is high, so that judgement is largely about knowing how new to your team(s) the changes you’re making really are.

Finally, agile starts with the vision of a wider community learning. Any fool can learn from their mistakes but the wise learn from others’ mistakes too. In the past 10 years, others have already tried out all the mistakes for you. Call in someone in who’s done it before.

Can a Contract Cope with Changing Requirements?

It’s been decades since software people started to think about how to cope with requirements changing during the course of an engagement, though other areas of endeavour have surely been doing it since the stone age. Literally.

The state of the art for software, and increasingly for other areas of IT, is Agile. Yet the recognition of agile in contractual relationships has lagged behind, which is odd given that a large part of IT is done by contracting someone.

When all is sunshine and daises this doesn’t matter. The time you really really want your written agreements to be right is when things go awry. If you’re doing business even with friends & family, it can help to have something in writing.

But how to write a contract for something when you know it’s going to change?

This problem came up in a linked-in architects’ discussion and I immediately reached for google to find my notes from Susan Atkinson’s presentation on Agile Contracts (I saw her present at a Rational User Group conference a couple of years ago). I reduced it to bullet points in /p1201/susan-atkinson-features-of-an-agile-contract, and she was good enough to drop by to correct & update it. She’s been developing an Evolve Contract Model with Gabrielle Benefield and the website should be up soon. Meanwhile there is a recent presentation on slide-share at Contract Metrics For Agile.

For those not yet convinced that there’s anything wrong with a waterfall-style contract and project, you can read the IEEE 2013 conference paper at http://www.slideshare.net/SusanAtkinson2/ieee-2013-the-flaws-in-the-traditional-contract-for-software-development. nb Open it full-page mode for easy reading.

IT Success and Failure — the Standish Group CHAOS Report Success Factors

The Standish Group have been famously (notoriously) publishing their CHAOS Report with IT project success/failure/challenged rates since 1994. “XXX% of all IT projects fail!” headlines are doubtless responsible for their fortuitous fame but they have also attempted to analyse ‘success factors’ over the years:

1994 1999 2001 2004 2010, 2012
1. User Involvement
2. Executive Management Support
3. Clear Statement Of Requirements
4. Proper Planning
5. Realistic Expectations
6. Smaller Project Milestones
7. Competent Staff
8. Ownership
9. Clear Vision And Objectives
10. Hard-Working, Focused Staff
1. User Involvement
2. Executive Management Support
3. Smaller Project Milestones
4. Competent Staff
5. Ownership
1. Executive Management Support
2. User Involvement
3. Competent Staff
4. Smaller Project Milestones
5. Clear Vision And Objectives
1. User Involvement
2. Executive Management Support
3. Smaller Project Milestones
4. Hard-Working, Focused Staff
5. Clear Vision And Objectives
1. Executive Support
2. User Involvement
3. Clear Business Objectives
4. Emotional Maturity
5. Optimizing Scope
6. Agile Process
7. Project Management Expertise
8. Skilled Resources
9. Execution
10. Tools & Infrastructure

Little changes at the top. Executive support & user involvement were noted in the 1970s as 2 main success/fail factors. ‘Agile Process’ is an evolution of ‘Smaller Project Milestones’ (the bit of agile that’s actually about process is “deliver working software frequently”, which is “smaller project milestones” in olde 1990s language). ‘Clear Vision and Objectives’ is re-branded as ‘Clear Business Objectives’

But note the varying evaluation of the importance of the people. At one level technical stuff will get done if and only if you have competent people actually doing it — it’s make or break. But so are all the factors above “Skilled resource” or “Competent staff”, albeit less obviously so.

Emotional Maturity is new. The cynic may note that the Standish group will sell you an Emotional Maturity Test Kit (the less cynical may say Standish are attempting to address a problem). Actually their analysis of emotional maturity is largely about character and behaviour which may be a sign that the English word ’emotion’ has grown in what it means compared to 20 years ago. They include arrogance and fraudulence; I can see arrogance as a symptom of emotional immaturity, but fraudulence may mean “I’ve considered what counts as getting ahead in our society and it seems to me that taking the company for everything I can get before they take me for everything they can get is the way to go”. Fraudulence is wrong, but ain’t always emotional. I think “personal maturity” — or just maturity — is the idea they’re grasping at. It’s about having good people.

Scarcity of essential success factors

But the top factors are not prioritisable. I think they are all essential. Rating one above the other says more about relative scarcity than relative importance. When it’s really hard to get competent, skilled, hard-working staff then that will be your top success factor. As it is, good executive support is harder to come by than competent staff. Apparently.

I’d summarise as follows:

  • Good people
    • who know what they are trying to achieve
    • with good involvement & communication with who they’re achieving it for
    • when well-supported

will succeed, if success is possible.


More serious researchers point out all that is wrong with the Chaos report, most notably:

  • unlike published academic research, the data we’d need to evaluate the claims is kept private so we can’t verify their data or methods.
  • Their definition of success is very narrow and doesn’t mean success. It means “cost, time and content were accurately estimated up front”. Which isn’t at all the same as success except in areas which are so well understood that there really is nothing at all you can learn as you are doing it. That’s not so common in technology projects.

For an alternative and probably more balanced view of the ‘state of IT projects’ I’d look at Scott Ambler’s annnual surveys: http://www.ambysoft.com/surveys/