The Scrum Hegemony & the Kanban Insurrection

One of the ideas I talked about in my Jax London presentation is something I call the Scrum hegemony and it deserves a few notes.

In the early days of Agile there was a tendency to equate Agile with XP, that changed a few years ago and Agile become (almost) synonymous with Scrum. I’m not saying Agile was XP or Agile is Scrum, just that to the uninitiated it can seem that way. (I blogged about this nearly 2 years ago now, see “Scrum is the new XP”.)

In many ways the Scrum people did a fantastic job of making Agile acceptable to the corporation. They had data and Harvard Business Review articles to cite, they didn’t ask the corporation to get into technical details (like TDD) and they had a friendly (English) name which avoided the word EXTREME! And most of all they had Certifications. O, don’t forget a pretty good marketing machine.

All this had the effect of making Agile acceptable to suited corporate types who didn’t know the first thing about software development but knew projects were always late. Ironically Scrum isn’t much more than XP, indeed, it is less than XP.

Consider XP: you can basically divide it in two. The bits about engineering (continuos integration, test driven development, refactoring, etc.) and the bits about managing the work (iterations, stand-ups, stories, etc.). Scrum, as documented concerns itself with the management side.

Granted Scrum expands on roles, Scrum adds some concepts like self-organising teams, adds some terms like backlogs and renames others (iterations to sprints) and adds burn-down charts but the management side of XP is basically Scrum, and Scrum is XP.

Purists might like to argue about which stole from which but the point remains: they are the same.

Scrum is devoid of the engineering practices, but as I’ve noted before in this blog: Scrum without the engineering practices is heading for trouble.

XP’s success, and the even bigger success of Scrum had the unfortunate side effect killing off most of the other Agile methods: FDD, ASD, Crystal, etc. Pockets still exists (especially with DSDM) but that is all they are, pockets. That was good for understanding but bad for experimentation and learning.

That’s now changing. The Scrum hegemony is now ending. Kanban, and perhaps other methods, are now offering alternatives. David Anderson’s Kanban insurrection is again offering an alternative. Kanban is again allowing the experimentation and variation in process that the Scrum hegemony has been stifling.

Don’t get me wrong, I don’t think for one moment Scrum is going to roll over and disappear, or that Kanban will dominate. Scrum will continue to be the Agile method of choice for corporations, it will be the 800 pound gorilla to use a phrase. But it will no longer be the only show in town.

Kanban is on the rise and drawing more attention to Lean, Software Craftmanship is on the rise and Tom Gilb’s work is being re-examined. There has long been a divide in Scrum between those who believe in “one and only one Scrum” and those who see “Scrum A, B and C” (I was going to post a link here to Jeff Sutherland’s blog but it appears he’s removed the post). Now there is a schism in Scrum: there are two bodies awarding Scrum certification, Scrum Alliance who’ve been around for a while and a Scrum.org backed by Microsoft and Ken Schwaber.

One of the good things about Scrum was that it was clear about what it was and was not - unlike Agile. This increasingly looks in doubt. As Scrum has grown more popular variations have set in, differences in certification and types of Scrum only add to those differences. The danger for Scrum is that it goes the way of the word Agile and becomes all things to all men.

That risk is echoed in the wider Agile family now. I welcome the rise of Kanban, not just because I think its a good system but because I think it is offering opportunities to think again about how we do things. But the end of the Scrum hegemony could leave the Agile as a whole fractured and incoherent, and decidedly not the type of thing corporations should be involved with.

Worst of all, it could see a new methodology war. There would be no winners here, only looses. Scrum and Kanban, and all the other methods, shouldn’t be rivals just alternatives. Unfortunately between the method zealots and in the commercial market I fear that message will be lost.

Jax slides

The slides from my Future of Agile presentation to this weeks Jax conference in London are now online. Although this talk started as a revision of last year’s Future of Agile (at ACCU and BCS Bristol) it ended up as a rewrite. The essential message is largely the same (key message: The future is lean) it brings out some new themes (e.g. software craftsmanship).

Later this month I’m presenting longer version of this talk to the BCS PROMS-G group in London as part of their Agile spring school, itself a repeat of the Bristol BCS Spring School last year. The longer version will include more on how to go about changing from where you are today to where you want to be.

Last words on architects

Time to bring this mini series to an end. I’ve talked about

• Segmenting Architects
• Architects who aren't
• Architecture or Design?

As a quick rule of thumb consider:

• The Product Owner (Produce Manager/BA): is concerned with the What
• The Project Manager: is concerned with the When
• The (your type of) Architect: is concerned with the How

And some closing advice:

• When you have a software system to design or fix, look to an architecture team not an individual. The team can share the vision in creating and exploitation.


• Never, ever, give someone the title Architect: give them the role yes, but never the title. Once you give them the title it is difficult to remove. And since you don’t know how their ego will respond you risk creating an problem. Architect is a role, not a title. Give people architect responsibilities but make sure they are still defined as a Software Engineer or whatever term you use were you work.


• The moment an “Architect” asks for an expensive tool to draw UML in then its time to let them go. UML can have a role but it isn’t worth spending money on. Expensive tools allow people to hide, architects shouldn’t hide. A cheap tool might be acceptable but don’t let them hide behind it.

Segmenting Architects

Continuing my examination of the architect role I think we need to point out there is not one architect role my several. There is no such thing as an “Architect”, only an “Architect of something.”

Rather than talk about an “Architect” with one word we really should use two words. The first word describes what they are an Architect of, and the second, well thats the word “Architect”.

Some examples should help:

An Enterprise Architect: One who is concerned with the systems of the enterprise as a whole and how those systems fit together. By definition this architecture in the big and it means making architects at the grand level and not being concerned about details.

So: the Architect might rule that all new systems should be in Java, and not C# but they should not concern themselves with Java coding standards or which design patterns the Java developers are using.

A Solution Architect: these architects get involved in the early discussion about what the solution will look like. They may be responsible for sketching it, they may devise a prototype, they may be involved in customer conversations around requirements because you don’t know what you want until you see the solution; and this means they have some business acumen.

You might say these are the guys who have the initial vision for the final product. Importantly though: they need to stay with the development from start to finish. They can’t walk away once they have sketched out the initial vision. They can hand over to someone else with time but they need to keep skin in the game to have legitimacy and so they learn how effective their solutions were.

Ideally, when you start working on a product/project you want one of these guys involved but you want them to change hats as the work increases and become: a software architect.

A Software Architect: This is were my interest really lies, these are the guys who are custodian of the design vision for a piece of software, or application if you prefer. They are responsible for ensuring the whole team shares the same idea of how the software is designed. As such they are more responsible than most for how the software looks (inside) now and in the future but they are not solely responsible. Software Architects should have more experience than other team members but their responsibility is to lead through teaching.

Software Architects must implement, they need code under their finger nails if they are to retain their knowledge and legitimacy.

Their work includes:

• Being a Senior Developer, hands on, they should have code under their finger nails
• Educating junior developers, sharing their knowledge, mentoring, teaching and training
• Guiding development towards a consistent and sustainable architecture
• Holding responsible for the shared technical vision and ensure it is shared
• Dealing with Conway’s Law: interfacing with non-technical manager types to ensure the technical and organisational architecture are compatible

You might like to note I’m not saying they create the design, they do not. Their responsibility is to help the team create a shared understanding which is the design, and then become custodian of that vision.

I’ve avoided mention of roles like Network Architect, these might well exist but not always. Maybe you can think of some more architects in your organization.

I’m also avoiding the term System Architect because you have to define what you mean by “system” - where does it start and where does it end? Potentially System Architect is “Architect of Everything”.

These roles will also vary by organisation size. In a large organisation you might find these roles exist as distinct roles, in small organisations they are likely to overlap. So an Enterprise Architect also needs to do some Network Architect.

This is understandable but problems come when one individual is so busy wearing many hats that they neglect some aspect of one of the roles. They try and do two or more roles and end up doing one (or all) badly. Consider an Enterprise Architect who combines his role with being a Software Architect at the same time. If the Enterprise aspect dominates they may neglect involvement with coding the application so they cannot speak with experience about the application. Or, the other way round: they are so busy being a Software Architect that they don’t keep up to date with emerging trends and neglect the Enterprise side.

Architects who aren't

Having cleared up some preliminaries, i.e. What is architecture?, we are getting closer to the big question: what do architects do? But I’ll continuing to take this piecemeal. In this blog entry I’d like to dismiss too groups of people who carry the Architect title but are not Architects.

The first group are “Architects by Seniority.” Some years ago I held a post with the title “Senior Software Engineer.” At first I though this might mean I was “the senior software engineer” but quickly realised I was one of many “senior software engineers.” The company conferred this title on anyone who had more than a few, about five, years of experience working as a software engineer. Or as I used to joke “anyone over 30.”

Some Architects get their titles the same way. My guess is this is more common on the services side of the industry were engineers are sold by the hour to clients and Architects have a higher billing rate.

A few months ago I was told it was common in the Indian outsourcing industry to confer the title Architect on engineers with 3 years experience. This is one data point, I don’t know how common that really is. Anyone out their know?

Unfortunately, some of the people who are given the title Architect simply because they have been around a while let it go to their heads. Which brings us to the second group who are Architects in title but not in practice: “Divorced Architects” or, as I think Joel Spolsky christened them “Astronaut Architects.”

These are Architects who sit around thinking big thoughts about “the system” but aren’t connected with what is actually happening. Just because you have the title “Architect” does not give you the knowledge or right to tell people what to do without doing it yourself. As Jim Coplien and Neil Harrison put it “Architect also Implements.”

If you are lucky these architects are pretty much harmless, they cost the company money, the developers tip their flat-cap to them in the morning but ignore them when they do work. If your unlucky their crazy ideas result in a messed up system and their egos get in the way.

Years ago I worked on rail privatisation, the Railtrack A-Plan timetabling system to be exact. It was on Windows NT with Sybase (yes, thats how long ago it was) in C and C++ with a little Visual Basic. 120 people worked on the system at the peak, of which four were architects and about 12 were coders, OK, maybe 16 if you include the SQL and VB guys.

But the architects came from a mainframe Cobol background so they designed a batch processing system, set down constraints and ways of working which just didn’t make sense for a client-server system. The company had a ISO-9000 system in place with lots of management so the result of this architecture was a lots of problems. Once they got into the code the developer just did what they wanted, the architects would never know because a) they wouldn’t get their hands dirty with code and b) they didn’t really know C let alone C++.

The project wound down and went into maintenance mode so I left. A couple of years later I found myself back on a much reduced project to redevelop parts of the system. Now we had about five developers, one architect part-time and a couple of dozen people tops.

We mostly ignored the architect, he saw one system and we saw another. ISO-9000 was nominally in place but widely ignored. The process worked a lot better. Occasionally we wrote a formal document to keep the formal process and architect happy but the real documentation was contained in “Rough Guides” which didn’t formally exist.

Moral of the story: Just because you are called an architect, just because you go to meetings, you aren’t an architect.

Published: 97 Things every programmer should know

Kevlin Henney’s “97 Things every programmer should know” (the website) project has now advanced from website to book. Yes, you can buy a physical copy of “97 Things every programmer should know” (the book) from all good, erh, online bookshops - I’m guessing it won’t be in your local Borders or Waterstones.



As I’ve mentioned before two of the 97 “things” are mine. Of which my favourite is “two wrongs make a right.”

What is scary is that I know many of the contributors - I mean, well enough to have drunk beer with at least of dozen of the, perhaps 30, contributors.

Many years ago I overheard a wise old programmer telling some recent graduates: “There are only 3,000 good programmers in the world... and they know each other.” OK, I can’t remember if it was 1,000, 2000, 5,000 or 8,000, I do remember it was thousands, not hundreds and not tens of thousands. I’ve no idea how accurate he was, but I’m more and more convinced of the second bit. The best guys do know each other.

And what 97 Things shows is: Kevlin knows more of them than I do which means he’s probably a better programmer than me.

Architecture or Design?

I mentioned the A word in my last post (Are there any System Analysts out there?). As regular readers might have noticed, I have over the years of this blog taken the odd pot-shot at Architects. But I’ve avoided direct comment on architect and architecture. Somehow it feels the time has come to address this debate.

I should say before we go too far that when I talk about Architecture I’m thinking software architecture. And when I talk about Architects I’m thinking about the architecture of software. I’m not thinking of network architecture, or business architecture, of course these topics are connected with software architecture but we need to narrow the topic down a little.

Nor am I talking about system architecture and system architects. System architecture is a particularly confusing concept because we first have to define the size and scope of our system: a piece of software is a system, so too is the computer it runs on and so too is the combination of both. So lets agree to leave system architecture to one side too.

Before we can tackle to subject of Architects I think we need to get a better understanding of architecture. So I’ll defer architects to another day and think about the nature of architecture today.

If we look up architecture in the dictionary then we find its all about design. Architecture is design. The word “architecture” (like the word “design”) is both a noun and a verb. Architecture is something you do (we may create a proposed architecture) and it is something you have, you software has an architecture whether it was design or not.

As an experiment, whenever you hear someone talking of “software architecture” mentally substitute the words “software design”. I don’t think you’ll find any loss of meaning.

Both design and architecture are, certainly in software systems and frequently elsewhere, part a deliberate attempt to create a particular outcome, they are also part emergent. How much is deliberate and how much emergent varies. As a result, the architecture (design) we finish with is something different to that which was planned.


(As an aside, we’ll talk about another time, that diagram is based on one from one of my favourite books, The Rise and Fall of Strategic Planning. There are close parallels to the way we relate to, and go about creating software architecture and business strategy.)

So architecture is design. Is it anything else? Anything more?

Architecture is more than design because the word architecture implies something bigger. An architecture is more than a design. You architect buildings but you design tents. Some of this “architecture as grand design” is just that, aggrandisement. It an attempt to make design into something grander. Personally I think design is a worthy and grand thing itself, you don’t need to aggrandise it any more.

In a software context there is the question of inside and outside. The term “software design” is often used to describe the external properties of the software, how it looks, feels, perhaps the features it offers. While
architecture often refers to the inside: how the thing hangs together and work. So there are “user interaction designers” but I’ve never heard of a “user interaction architect”.

I have long argued that software design exists in every line of code. Writing code is designing software. Certainly this fits with the “architecture is the inside” line of thinking but it doesn’t fit with so well with “architecture as bigger”. Somehow, while I happily argue that the choice between a FOR-loop and a WHILE-loop is an act of design, it seems wrong to argue that this is an act of architecture. But, according to own logic, that is what I am arguing.

The architect Ludwig Mies van der Rohe is reported to have said: “God is in the detail”. He wasn’t the first to use this quote but it does summarise his approach to architecture. He was an architect who was concerned about details. There was no lower bound for his architecture. So on that basis, Yes, whether you use a FOR-loop or a WHILE-loop, a bunch of IF-statements or a CASE-statement, you are making architectural decisions.

Architecture is design, it scopes up to the very big but it also includes the small details, because you just don’t know when the small details are going to become important.

Are there any System Analysts out there?

Has anyone met a System Analysts lately?

I ask because I’ve been looking for over a year and can’t find one. I should say immediately I’m not looking to hire one, rather I want to find out what they do. I’ve looked and I’ve asked and the role seems to have disappeared from organizations. Or rather, perhaps I should say the title has disappeared; the role still exists in some places, for better or worse.

My belief is that the System Analyst role has been divided up between the Business Analyst and Architect roles. Like a System Analyst, a Business Analyst will look at what is required from a computer system but they (should) look predominantly from a business perspective, not a technology perspective. Like a System Analyst, an Architect will look at the current systems and how it they work and fit together and how they should work and what new work is needed.

(Note: Of course the Architect’s role is itself a complex issue and needs subdividing, that will need to wait for another blog entry.)

I’ve run this idea past a number of people in the last year and I’ve yet to have anyone seriously disagree. In order to validate it further I went to my old (1992) copy of Roger Pressman’s Software Engineering [[link]] and found the following definition of System Analysis:

“... system analysis defines the roles of each element in a computer-based system, ultimately allocating the role that software will play”

Pressman doesn’t define the System Analyst’s role still, it seems logical that a System Analyst is someone who does system analysis. Later in the book he gives the list of the objectives of system analysis:

1. Identify customer need
2. Evaluate the system concept for feasibility
3. Perform economic and technical analysis
4. Allocate functions to hardware, software, people, database, and other system elements
5. Establish cost and schedule constraints
6. Create a system definition that forms the foundation for all subsequent engineering work

If you look at that list 1, 3 (economic) and 5 fit squarely in the BA function while 2, 3 (technical) and 6 fit in the Architect role. The BA is concerned with the people element of item 4 (and the implied process change) while the Architect is concerned with hardware, software, db, etc. Of course the two functions need to work together here because there are trade-offs.

So that’s it, System Analysts no longer exist, an open and shut case. Except...

I’ve also observed what BAs do and I think some BAs are filling a System Analyst function while holding a Business Analyst title. This is wrong. A Business Analyst should be concerned with the business need and what will deliver value to the business.

In other words: BA should be concerned with the “what”, not the “how”.

When a BA steps into the “how” they are engaging in design and enter the world of Engineers and Architects. There are, at least, three good reasons why they must not do this:

1. By specifying the “what” they restrict the options available for the development team which means they prematurely close off discussion of how needs can be best and most effectively satisfied.
2. Engineers and Architects tasked with designing solutions have the training, experience and skills necessary. One wonders if the BA who suggests “how” has equal competences, and if they do, why are they working as a BA rather than an engineer?
3. Specifying the how undermines the engineering team and encourages them to take a box-ticking approach. This in turn affects quality.

In undertaking design (synthesis) they are removing their attention from analysing the what - making more work for themselves. Synthesis and analysis are very different activities and are deliberately separated.

(Of course, on a small team the same person may find themselves engaged in analysis one week and the following week tasked with creating the solution. In such cases it is still worth considering the two as separate activities and getting some mental separation.)

I’m commenting here on what I’ve observed, its not that I have a dim view of System Analysts - if there are any out there I’d love to hear your comments. In fact, there are two reason why I’d like to see the return of the System Analyst role.

Firstly, as Tom Gilb would be quick to point out: there is an important role for System Engineering in the IT development. IT work which is too tightly focused on a piece of software, or a point solution, risks ignoring the role IT plays in the wider system. There is a need for more System Engineering in our IT development efforts and part of that is System Analysis (although maybe a different type of system analysis.)

Which raises the question: who in a typical IT development team is best positioned to take on the wider system, interdisciplinary and engineering questions which arise in large development?

That sounds like an Architect to me.

Secondly, in so much as a System Analyst is one type of Architect I think it’s a better title because it is less prone to ego-bloat. Unfortunately, some people let the title “Architect” go to their head. Once they get to be “An Architect” they see no reason to code any more or get their hands dirty with detail. They prefer to sit alone, draw UML diagrams and issue edicts. I’ve heard them called “space cadet” or “astronaut” architects. They become divorced from that is really happening.

So purely on the grounds that I suspect the “System Analyst” title less prone to pomposity than “Architect” I think it should be used.

New to Agile? Want to know which tool to use?

There is a re-occuring question I am asked from time to time, and I see on discussion forums. It again appeared last week:

“We are new to Agile and are looking to adopt a tool for managing the process... which tool would you recommend?”

There are variations on this question (replace Agile with Scrum/XP/Kanban/whatever, or replace “managing the process” with requirements/development/testing) or maybe its put as “Does TFS work with Scrum?” or “Is Target Process the right tool for XP?” but its the same basic question.

Anyway, I try not to take the bait on these but last week I couldn’t resist and answered it. My answer solicited a positive response from several people so I thought I’d share my answer with more of you and expand on it a little:

For anyone new to Agile (all flavours, Scrum, XP, etc.) I strongly advise avoiding all software tools for managing the process until you get the hang of working in the new manner manually. You will have a faster and more fulfilling learning experience if you do it by hand - pens, cards and white board - for a few weeks before you look at a tool.

There are several dangers with tools:

• You may mistake the tool for the process: e.g. using Rally doesn’t make you Agile
• The tool might not work quite the way you need to work: in your company the tool might not do something you need to do
• The tool might be too strict: when your learning you need a bit of slack
• People may communicate through the tool rather than face-to-face
• You may spend time customizing the tool when you should be focusing on the actual work
• And, when you find things don't work quite the way you want them to it is much easier to change a card or a board than change the software.

Something magical happens when people work with cards. Abstract “work” becomes real. We relate to it in different ways when it has a physical presence and you can move it about. You don’t get that with a tool.

Once you have a tool the tool easily becomes an impediment to further change:

• To change you need to change the tool
• You need time to reconfigure the tool (if you can)
• You need time to move your data to another tool (if you can)
• You need to justify the change of tool to those who paid for it: “We paid $10,000 for these licenses 6 months ago, what do you mean you aren’t using it any more?”
• You need to justify spending money on another tool: “And you want me to spend another $5,000 on another tool? Will you use it this time?”
• And you have invested yourself in the tool, you don’t want to admit you got it “wrong”.

Nobody ever got fired for spending too much on index cards, or for throwing a pack away.

Yes I know there are genuine reasons people want to use a tool to help with their work. But choosing the tool before you change is putting the cart before the horse. In my opinion people and teams which spend time evaluating and deciding on their tool are resisting change.

Damn the torpedos just do it!

Do it by hand to start with, give it about 3 months like then then look at some free tools, don't waste time on customizing anything. Give it another 3 months then you should have the experience to find the best tool for your team.

Don’t be scared to change tools - and don’t invest so much in one tool that you can’t change in a few months when you realise its not right.

I’m not saying “Don’t use tools”. To be honest my preference is not to use them, stick to paper, pens and boards. However, I recognise that on some occasions they can help (remote working springs to mind.) But, before you start using one be clear what you need to get from it.

The thing is: Agile is about learning, and you have a much better learning experience when you are manually managing the tasks. If you need a tool to manage them you probably have an over complicated process. When you insert a tool between you and the process you loose sight of what is happening. The tool is a box labelled “magic happens here” and complexity can set in.

There is a story. Its about Jack Kilby - not heard of him? You should have done, he was co-inventor of the Silicon chip. A few years after inventing the chip he helped Texas Instruments develop the calculator. But he regretted the passing of the slide rule.

He said: the slide rule gave engineers the numbers but they needed their intuition to know were the decimal point went. Was the answer 123,456,78 or 123.45678? The calculator took that away and he thought that made for poorer engineering.

Using an tool to manage your Agile process is like that. It removes part of your intuition, part of your understanding.

'Wired for Innovation' and the Trouble with business value

I stopped reviewing books in this blog a while ago but, having said a few words about Domain Driven Design Using Naked Objects last time I want to say a few words about another book I’ve just finished reading: Wired for Innovation: How Information Technology Is Reshaping the Economy.

For anyone who is concerned with the future of IT, technology in general, and improving the state of the art this book is well worth reading. At a little over 100 pages and £10 it is worth the investment.

The book is written by two academics, and it is a bit academic in tone and approach but there are some gems in here. Not only have the authors studied how IT is used they have made serious attempt to measure it. In fact, if you have read anything by Brynjolfsson before there is a good chance it was his work on the “productivity paradox.”

The authors know about measuring IT and have some fascinating statistics. For example, did you know that in the last couple of decades “IT intensive” companies have grown much much faster than those which are not IT intensive?

I don’t want to review the book but I do want to highlight some of the points the authors make for the benefit of those who won’t read the book. In particular, there are some facts here which need to be considered by those who advocate a focus on “Business Value” when developing software (of which I include myself).

Firstly the book resolves the “productivity gap”. This was the observation in the late 1980’s that despite all the investment in productivity enhancing IT there was no resulting increase in productivity in the production and GDP statistics.

The explanation turns out to be: time. There is a time lag between investment in information technology and when the benefits are seen. This has closed somewhat in recent years, instead of decades it is down to years but it still exists.

So: problem number 1 for the business value crowd, How do you measure business value when the benefit will not be seen for two or three years? Or longer still? How do you create a feedback loop when your developers are working today and you can’t measure the value for two years?

The second issue we need to pay attention is “the complementary nature of IT.” It turns out, when you look at the numbers that IT by itself doesn’t delivery a whole load of benefit. To see real benefit you have to combine it with other practices. There are seven:

• Move from analogue to digital processes
• Open information access
• Empower the employees
• Use performance based incentives
• Invest in corporate culture
• Recruit the right people
• Invest in human capital

If you want to increase “business value” then do all these things as well as your IT work. Trouble is, many of these things fall outside the bounds of your typical IT project. (And in part doing these is why there is a time lag.) If you don’t do these things then you will fall a long way short of maximising business value.

Put these together and you discover: a successful IT project requires organisations to change their processes. Which leads to another issue the book brings out: should business processes be counted as assets for a company?

After all, we count the hardware and software used for the process, why not the actual process? We invest in it, we spend money on it, why not count it?

This may sound irrelevant but it is important because: failure to count processes as assets means companies don’t invest in them. It processes were counted it would become easier to justify the seven things listed above. If processes were assets then money spent on them would come off one account and appear on another so it is easier to justify.

Where all this is leading is a stark reminder, next issue, that in many businesses, and among many managers, IT is considered intangible. The authors don’t challenge this assumption, to be honest, there is good reason why IT is seen as intangible. But it does mean that someone who talks about “Business Value” looks a bit out of place when “everyone knows” its intangible.

(Why IT is seen as intangible is probably another blog entry.)

Next, a lot of IT has delivered “value” it isn’t countered. Take for example a Google search. How much is a search worth to you? How much time and effort would you need if you had no Google?

But, while Google’s revenue is countered by the Government those searches aren’t. In fact, nobody, anywhere, attempts to put a value on Google searches.

Or take Wikipedia. How much is it worth? If I want to know how the steam engine works I can go out and buy a book. That will be counted. But if I read it on wikipedia it isn’t.

These are just examples of how IT systems change things and add value which isn’t countered. It is the kind of challenges we are up against when we try and measure “business value” in IT work.

And its why, for anyone who claims to know about measuring business value in IT, this book is worth reading.

Naked Objects and ACCU London January 2010

I am very excited about the next ACCU London meeting when Dan Haywood will be speaking about Naked Objects. The meeting is open to all and is free, just check the ACCU website for details.

I’m excited about this talk because Naked Objects is one of the few technology based approaches to software development which I think holds real promise for better development. This is because the Naked Objects philosophy is based on a very different approach to most software development. Rather than view the end user as some kind of inconvenience Naked Objects treats them as a problem solver who wishes to solve something.

I read the original Naked Objects book by Richard Pawson and Robert Matthews a few years ago and the idea has been with me ever since (I reviewed the book in an earlier blog entry). Its the difference between treating users as adults and not children to my mind. Rather than the designers defining processes in the software they give users the tools to resolve the issues their customers raise. This approach respects the person using the software. It moves the conversation from business processes to customer service; and it fits far better with piecemeal growth over big-bang change.

Dan has just published a new book on Naked Object, Domain Driven Design Using Naked Objects and I’ve been lucky enough to have a sneak preview. This is the first technical book (i.e. one with lots of code) I’ve read for a while and I enjoyed it. So here is potted review... Dan sets out to explain the Naked Objects framework. Yes, Naked Objects is not just a philosophy it is the framework too. No need to invent the wheel, here it is; and it seems that framework has matured quite nicely.

He is passionate about his subject, I’m almost itching to download this stuff and start coding myself - arhh, if I could only prioritise coding for fun above the other things going on in my life. The writing is very clear and to the point with a little bit of humour. His instructions for getting the environment set up for the example code and case study is clear.

There are plenty of code samples and screen shots to illustrate what is going on which is nice but... On the downside the book is nearly 400 pages long which means it yo are unlikely to carry it around much. I read a PDF version so I didn’t suffer too much.

I sometimes seem to be the only person I know who has not read Eric Evan’s Domain Driven Design book. Initially I thought I might be at a disadvantage reading Dans book but he explained just enough to get me through. Indeed, I’m now intrigued and plan to get a copy of the DDD book.

Sometime ago I asked Steve Freeman “Whats all the fuss over domain driven design? What is it?” to which Steve said: “Its about doing objects correctly, the way we should have been doing them all along.”

Everything I’ve learned about domain driven design since then fits with Steve’s description. It seems to me that domain driven design and naked objects were made for one another so I’m glad to see Dan’s book.

And I’m even happier that he’s speaking to ACCU London in a couple of weeks!

McKinsey on Agility

A recent McKinsey quarterly has a piece on organizational Agility, “Competing through organizational agility” by Donald Sull. It s a reminder that “agile” means something outside of the software world.

That said, the piece is a little disappointing. The piece doesn’t say anything particularly new. The only insight I gained from it was separation of agility into: Strategic agility, Portfolio agility and Operational agility. It would have been nice to know if you can have one without the others.

The main article also contains a sidebox which suggests some companies are centralizing decision making to improve agility. Personally I find that idea a little crazy. As far as I am concerned centralized decision making runs counter to agility for two reasons.

First it moves power away from those closest to the action. Those who deal with the customers, market and problem are the best place to make decisions. Moving decision making to the centre is disempowering and adds several layers of message passing.

Second centralized decision making is too often slow, bureaucratic or politicized. It takes time for the centre to realise a decision needs making, time to gather the information, time to make the decision and time to send out the decision.

Interestingly some of the examples given in the piece (e.g. Zara) are the same example cited by the Lean guys. More evidence that Agile is Lean by a different name.

The return of XP?

An interesting prediction from Kevin Rutherford for 2010: “I predict that 2010 will be the year that eXtreme Programming returns to centre stage.”

I tend to agree with Kevin, while his logic is sound I would offer an alternative rationale for the return of XP. It goes like this...

XP can be viewed from two perspectives: project or engineering practices.

The first of these is basically Scrum. The cognoscenti might debate which came first and which borrowed from which but basically the approach is the same: short time-boxed iterations. Yes Scrum adds in Scrum Masters, Product Owners, self-organizing teams and such but while XP’s description is more basic they have broadly the same approach.

As to engineering practices, there is a growing Software Craftsmanship movement which is aiming to put these back on the agenda. While Scrum has been centre stage in the Agile world many of the engineering practices have been absent. Uncle Bob Martin has been talking about this for a couple of years and I’ve observed it myself (see my post about the Scrum Wall.)

Scrum gained a lot of popularity during 2008 and 2009 but too many of those teams adopted the project management bit without the engineering practices. While that approach can bring benefits it also stores up problems for the future. As more teams take this approach more teams will see these problems and more teams will need to add back the engineering practices and take craftsmanship seriously.

Add engineering practices to a Scrum team and it isn’t very different from XP.

The question Kevin leaves unanswered is: XP 1 or XP 2? For me its Extreme Programming, first edition, “the old testament.”

Now, to extend Kevin’s prediction. I hope we will see the return of “requirements” in 2010, or rather, more focus on “business value” delivery.

The “what are we building?” question has been underplayed in Agile too date. This means the Product Owner, Customer, Business Analysts and/or Product Manager roles (call it what you will) needs to have more attention. Fixing development is the easy bit, the difficult bit is doing the right thing. But, you can only really address that question once you can deliver.

Events for next year

I have some speaking events booked for next year which might interest readers:

• 23 February, Jax conference London: I’m updating The Future of Agile presentation for the conference
• 23 March, BCS PROMS-G group London are running a repeat (with updates) of BCS Bristol’s Agile Spring School, if you miss The Future of Agile at Jax then catch it here
• April 2010, ACCU Conference, Oxford: New presentation bringing together some ideas into 10 Steps to Agile Requirements
• 20 May, Software East in Cambridge: Just a date in the dairy so far, details are still being sorted out

I hope to see you at one of these.

Happy New Year and all the other seasons greetings!