Thursday, December 22, 2005

Software Factories Skepticism

I'm no expert on Software Factories but frankly I am a skeptic. I have spent a day or so reading about them on the InterWeb at the behest of one of my colleagues. There are several very well written articles on Software Factories out there. I particularly like the Jack Greenfield articles on the Microsoft site (Parts 1, 2 , 3 (where's 4 BTW?)). There's no doubt the Software Factory proponents are very articulate and maybe that's one of the things that makes me skeptical?

There is no conflict between Software Factories as a basic idea and Agile. Indeed Jack Greenfield acknowledges, "modest gains in productivity have been made over the last decade, the most important perhaps being byte-coded languages, patterns, and agile methods". I'm not sure about the first two, but I'd agree with the 3rd.

Where my skepticism starts building is around the following points:
  • The Software Factory arguments sound a lot like the old Object Oriented/Reuse Library ideas. I used to be part of the Reuse Library effort at Morgan Stanley in the "early days" of adoption of objects in finance, so I am am familiar with the pitch. The issue which arose was that as much as you ended up with tools, frameworks and configurable components the productivity only came in when the users of the libraries and tools really understood the whole kit and could apply them. This required a lot of learning, which meant a lot of time before becoming productive. Forget "big design up front", this is "big learn up front". Clearly this can be solved by having "domain" experts learning on somebody else's penny before having to pay for them to build your system. But isn't this just reducing the accounting cost of a single project by ignoring the cost of the learning hump?
  • On a similar vein, I find it curious that a lot of the people from the early days of Objects and Reuse Libraries are the same people involved in DSLs and Software Factories (e.g. Steve Cook, Alan Cameron-Wills, etc). Same arguments and ideas, different century? Are better tools and larger distribution the answer? Maybe there is a flaw in the model that made it not live up to its promise the first time around?
  • Part of the argument for Software Factories is "the progress of the level of abstraction" that developers use to create systems. In my experience increasing abstraction often leads to reduction in productivity. The quote Jack Greenfield uses is from Smith and Stott's OOPSLA paper: "The history of programming is an exercise in hierarchical abstraction. In each generation, language designers produce constructs for lessons learned in the previous generation, and then architects use them to build more complex and powerful abstractions.". My problem is that the more abstract you become the more strongly defined (and smaller) your context must become in order to maintain a productive level of relevance. Without narrowing the context, the more abstract you become the more meaningless the artefacts become. My experiences with abstract frameworks and developers trying to use them led me to question abstraction. The XP approach of "create the value then refactor" was a better approach IMHO which still recognised the value of abstraction but maintained a practical grip on the scale of the context. I was also influenced by a quote from Joseph Joubert:
"How many people make themselves abstract to appear profound. The most useful part of abstract terms are the shadows they create to hide a vacuum."
  • The value in Industrialization in manufacturing came mainly from the change in the practices associated with creating goods. New tools were created to match the new practices and definitely increased the productivity too, but ask the question in reverse. If the specialized machinery for creating components had been created and applied with a craftsman process, would the productivity have increased as much as happened through purely changing the practices to production-line?
  • I believe these tools are emerging from the Agile community at the correct level of abstraction required for necessary productivity. IDEs with refactoring tools, Open Source frameworks for persistence, messaging, etc. Are these not the same elements of a Software Factory? There is a way of looking at APIs and scripting as DSLs.
  • An Agile team I believe they create their own Software Factory for there own domain through disciplined practice. This may appear to support the Software Factory argument, but there's a big difference: the people. Tools and documentation by themselves are not sufficient without the people who share and build the context the abstractions exist within. I would suggest that a manufacturing factory without people is pretty useless - indeed a manufacturing plant without people who have some idea how to use the tools is not much better. Possibly the term 'software factory' would be more appropriate for refering to a team of people who can produce systems using tools?
  • Where is the demonstration of Software Factories improving productivity? I am struggling to find evidence. If someone has good data please show me! I find plenty of opinion. I find plenty of confidence. But I find no evidence?
There is a business model that is sometimes refered to as "selling shovels to gold prospectors", that is to say that there is better money in selling the tools rather than taking the risk of striking it lucky. This definitely has a hint of that to it, but it feels more like they're selling divining rods, magic maps, voodoo incantations, lucky rabbits feet as well as shovels in a whole kit - and if you "use them properly" everything will be perfect!

I have no doubt if they achieve the essence of Software Factories in a coherent, understandable way then combining Agile Development with Software Factories will produce productive software delivery. But I currently believe its the Agile rather than the Factory that is the productivity boost.

I recognise my own skepticism is not necessarily useful. I am reminded of George Bernard Shaw:
"Every person who has mastered a profession is a skeptic concerning it. "

There is a strong possibility that Software Factories may be a better way of looking at IDEs, APIs and Frameworks. And maybe I'm the wrong person to measure the effort having been in software so long - but I don't see the evidence that this will help software development productivity or quality.

Friday, December 16, 2005

Winning an Award for Being Agile

I came across this article describing how a game company won a industry prize for using Scrum. I can't decide if this is good or not? Maybe I'm just jealous ?

Thursday, December 15, 2005

Agile and Organizational Change Management

Agile System Delivery in itself is not the main problem when dealing with clients. They want the benefits: regular delivery every 30 days, high quality, ability to change their minds, etc. They understand it, they understand to an extent why it might work but there is always "resistance" to the adoption of Agile practices. This is because you are trying to get the people to change the way they behave and Agile by itself does not address this process.

The field of Organizational Change Management (OCM) addresses the issues arising when trying to change the behaviours in an organization, but on the whole whenever I talk to Agile coaches or consultants they seem to ignore the fundamentals of OCM and are often ignorant of them! Next time you meet an Agile consultant ask them who John P. Kotter is?

Agile consultants, or even those who wish to have Agile adopted in their teams, need to become more aware of OCM techniques and tools. Of course there is the issue of what is the useful stuff in OCM? There is such a huge volume of stuff out there and on the whole it is fluffy, touchy, feely and frankly useless.

There are one or two classic pieces on why Organizational Change fails, such as John P. Kotter's "Leading Change: Why Transformation Efforts Fail" in the March-April 1995 Harvard Business Review (a summary here). These are well worth reading as they contain real tools you can use to start thinking and structuring an approach to the changes required in your context for Agile to be adopted and used successfully.

Let me give an example:

Recently, the Harvard Business Review published the Boston Consulting Group's change assessment model called the DICE framework. The DICE framework has been around since the late 90s and is interesting because it is an easy metric that can assist you in understanding the likelihood of success in a change effort. It is based on "hard factors" as the authors describe them rather than the fluffier stuff you normally see in change models. More importantly the metric is derived from a statistically significant study of 225 change programmes and has been shown to be useful in 1000 or more since.

So why am I waffling on about the DICE model? I think it is useful for looking at the adoption of Agile and the change process associated with it - particularly because one of the hard-factors used in the metric is the "Duration" or rate of review of progress. Since a major behaviour in all Agile approaches is Small Iterations and regular reviews associated with them, you may start to see my point?

The DICE model consists of a score generated from a metric in 5 variables:
  • Duration - the amount of time between reviews (or duration of change program)
  • Integrity - the ability of the team to deliver what is required
  • Commitment - two variables here, C1=commitment to change of top management, and C2=commitment to change of employees effected by change
  • Effort = the perceived effort over and above normal workload that the change initiative demands

These variables are scored in a 1 to 4 point range and then plugged into a formula:

DICE = D + 2I + 2C1 + C2 + E

The score is then correlated on a distribution graph which shows you if the change effort is in a Win, Worry or Woe state (management consultants do like their alliteration!)

So what does this tell us about Agile Adoption? Given that the best score of 1pt in Duration is given for review points that are at least 2 months apart, you may see that Agile is already on a winning roll! In fact, I would suggest 30-day Scrum Sprints and XP iterations might be allowed a cheeky 0.5 pt score, but its not my model and that may be cheating.

So what of the other factors?

I asked about 20 people I know who are Agile people about what they thought teams perceived the effort of beginning to adopt Agile was. After getting through the "it depends" qualifications, I found that there was a average coming out of about 35-45% extra perceived effort! (generally all 20 said the reality was that Agile was actually less effort!). In the DICE model this is a big factor and would fall into the poor 4pt range.

The Integrity and Commitment factors are more complex, as they are so context dependent. To score low figures in the Integrity category you need good team leads and at least 50% of the team's time being spent on the project, so to me Agile projects would never score the poor 4 but would always exist between 1 and 3 pts. With commitment, neutrality will score about 2, 3 if people are being divisive.

So what does this mean? The DICE model with these figures means that Adopting Agile processes are hovering in the Win-Worry zone, but not the Woe zone. This implies if you can get a team to start adopting Agile you have a an above average chance of it succeeding compared to other approaches to improving software delivery.

But you're not out of the woods. This DICE model points at working on several factors to improve the success of Agile adoption:
  • Senior Management Commitment - the more clear, consistent and definite the senior management can be about why adopting Agile is important the better
  • Team commitment - ensure the team understands why it is worthwhile them changing their behaviour. Help them construct a "what's in it for me?" answer
  • Integrity - there is no substitute for a strong team lead who gets why the change is needed. Make sure there is a leader. And make sure the team members are committing more than 50% of there time to behaving in an Agile manner on the project
  • Effort - do not under-estimate the impact of the "perceived effort". A slow adoption approach may pay off better than an all-or-nothing. Break the perceived 40% overhead into 10% chunks - for example, adopt the Scrum practices and slowly feed in the XP practices as they are palatable to the team (but keep the vision of doing them all finally). According to the model and my numbers doing this alone would move you into the Win zone by itself

Tuesday, December 13, 2005

MSF for Agile Software Development - You've Got To Be Kidding, Right?

Matt Davey pointed me at the MSF for Agile Software Development Beta. Damian Guy and I read through it - its a very good laugh! I would like to thank Microsoft for producing such a magnificent pre-Christmas spoof for our entertainment. I recommend it for your geek office party.

Hold on - maybe they're serious?? If so this is a real problem.

This is a terrible whitewash of the MSF product with an Agile brush for the purpose of marketing. The phrase which really rubs me the wrong way is in the Principles section of the Overview:
"This approach helps create an adaptive process that overcomes the boundary conditions of most agile software development processes while achieving the objectives set out in the vision of the project"
What the hell are you talking about? What boundary conditions? They don't define them anywhere. Is the boundary the need not to use the MSF product?

I cannot see much in here that would help you get any more Agile than you would be using normal development practices. Further a lot of the statements in here are non-sensical to an Agile ear, for example:
  • Under the Role>Developer>Fix A Bug>Step-By-Step it describes the process as fixing the bug THEN write the test to prove it works. Clearly the Agile practice of Test Driven didn't quite get through?
  • There is a section in the role>Developer>Implement A Development Task>Step-By-Step that describes doing a code review and says "Stay in the zero defect state". What? When do you not operate in a zero defect state?
  • The Role of Architect clearly describes a "big design up front" approach
  • It is very light on any Practice description - although a practice described in the "Pride of Workmanship" Mindset is "giving projects code names to clearly identify the project". Wow.
  • One of Damian's favourites is the diagram at the bottom of Overview>Team Model under the Scaling Down subtitle. This recommends which roles not to try to share in individuals if you scale the project down. It recommends not confusing people by combining the roles of Developer, Tester and User Experience. Errr...that's, like, completely opposite to most Agile thinking?
  • The Project Manager appears to be very busy estimating Scenarios, Development Tasks and Testing Tasks. Thankfully the MSF for Agile helpfully co-ordinates this into Microsoft Project so he can print out a Gannt chart for developers
  • The list goes on....
I thought Ken Schwaber's comments on this were very interesting, too.

This is an abuse of the Agile ideas for vending the same old tools and maintaining the same behaviorial practices. There is nothing in here about the practices you use to achieve valuing your people over your tools. There is nothing in here that would create a self-organizing complex adaptive Agile team.

If you're looking get the benefits of Agile Delivery, don't start with MSF for Agile.

They're using the words but not singing the tune.

Monday, December 12, 2005

Breakfast in NY with Ken Schwaber

Finetix hosted a breakfast for about 30 senior people from NY banks who were interested in hearing about Agile in Capital Markets. Ken Schwaber came along to add further weight to the Scrum argument.

We took a reasonably Agile approach to the session: we did a basic introduction to Agile, Scrum and XP including how they dovetail and what the benefits are when building Banking systems. We then opened the floor to very interactive Q&A.

Most of the questions were not a surprise:
  • Can you do this if your QA is offshore? [yes, and...but...]
  • Do you mean do the architecture in 30days? Then the design in 30days? etc [no...]
  • Can you do Agile without XP? [yes, Scrum...but...]
  • Do you mean get the QA involved early to sort the tests out? [kind of but more...]
  • Can you do this with junior people, you've all done it with good people? [no, done it with all sorts of people...]
And most of the statements were challenges that were straightforward to handle:
  • Developers won't want to Pair Program [not 100% true, and...]
  • You need documentation for when the system gets taken over in 3 years time [you ain't gonna need it if you don't deliver a system PDQ]
  • You need to design an architecture first! [er, no you don't if...]
  • 40-Hour Week, hah! I work that a day! [empirical data 40 useful hours...and you can do other things...]
It was great having Ken there to lend examples and data from other large, successful organisations outside Banking. Thanks, Ken.

We did something right as I ended up visiting several institutions as a result of this breakfast to further the Agile discussion in their particular contexts.

And in each place I ended up going through the traditional conversation along the lines of:
They: "That's what we did when [things went wrong]. We had [horrible deadline X] and we worked as a small team, met every day, did what it took and delivered"
Me: "Yes. Did it work?"
They: "Yes - but it nearly killed us working at that rate"
Me: "So what happened afterwards?"
They: "We went back and took time to rearchitect the system properly over [n>10] months"
Me: "Did that succeed?"
They: "Sort of - it was late. And it wasn't as good. And the users weren't happy"
Me: "So why did you change your successful way of working?"
They: "Errr"
Furrowed brows
They: "We couldn't keep working at that pace!"
Me: "I agree. You clearly know what it takes to succeed you just keep going back to old habits when the pressure is off. Why not work that way all the time, but at a reasonable pace, with reasonable deadlines?"

(Its becoming unamusing to repeat this conversation with people)
The Banking IT world knows this model of delivery probably better than any other! The hard, high pressure deadlines are often externally imposed by regulations and law. It is amazing that Financial institutions haven't embraced Agile development more.

I found there was a lot of misunderstanding about what Agile Delivery entails. Everything from fear of XP and believing its just about programming, to the "it's a license to hack" attitude. Agile seems to be a dirty word? Why I wonder? Is it the fear of change and not understanding the impacts, or is it something more?

Thursday, November 24, 2005

Agile Letter to The Guardian

I never really believed it was worth writing to newspapers, however, I was irritated by an article by Ed Hasted in the Technology Guardian sufficiently to respond. I got a call from Bernard Horan to tell me that they'd published an excerpt from it on the letters page!

So now I believe in writing letters to newspapers - look out Mr. Murdoch!

Pity they didn't put my contact info in, that would have been interesting...

Monday, November 21, 2005

XPDay and Buying a Beer

So XPDay is nearly upon us. Well worth going to if only for the social events on Monday and Tuesday! As per my previous blog entries I am a fan of the social event as a useful practice. If you study the programme closely you will notice that Finetix is sponsoring the drinks on Monday night - clearly I've managed to convince others of my view :-)

If you're going to XPDay please do come along, have a drink and start a discussion or argument of your choice. Myself and several of my colleagues including Matt Davey and Damian Guy will hopefully be coming along. So you've got time to prepare your attack....