Posts Tagged ‘Scrum’

Scaling Scrum to the Enterprise and the Challenge of Dilbert

Friday, June 18th, 2010

Scrum has shown itself to be a successful approach to software delivery in small organisations. There is sufficient enthusiasm to lead people to wonder if it can be scaled successfully to work at the enterprise level. Scrum has not had rapid uptake in large organisations, because large organisations are suspicious of its ‘self-organising’ nature and lack of rigid control. Simply the fact that Scrum does not have a recognisable project plan leads some people, often those working in the Project Management Office (PMO), to view it with hostility. Where hostility exists within the organisation, it is little wonder that Scrum teams fail to thrive.

To some degree the antipathy with which the PMO function views Scrum is mutual. This is captured in the 2001 Agile Manifesto, which can be viewed as a software engineer’s charter that bemoans the obstacles put in the face of programming teams by ‘Dilberesque’ corporations.

In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the begeebers (you can’t use the word ‘shit’ in a professional paper) out of traditionalists. Quite frankly, the Agile approaches scare corporate bureaucrats, at least those that are happy pushing process for process sake versus trying to do the best for the “customer” and deliver something timely and tangible and “as promised” because they run out of places to hide.

Jim Highsmith (2001) from [http://agilemanifesto.org/history.html]

The opinion expressed by Jim Highsmith is undoubtedly, in some cases, true. Where it is true, Scrum will struggle to make in-roads. Where the organisation is driven by the market and less by the needs of the organisation to service itself, Scrum has more of a chance in scaling to the enterprise. Ultimately for Scrum to work, things have got to change, and everybody knows that change is difficult. It is unlikely to happen driven from the bottom up without support and direction from the top. Perhaps one definition of an organisation that is Dilbertesque is the characteristic whereby it is dominated by layers of middle management and senior management becomes remote. So it is impossible to define scalable enterprise Scrum without first defining the characteristics of the organisation where Scrum can flourish. A seed cannot grow in soil that will not support it.

As an aside, the interested reader would do worse than to read:

(http://monster-island.org/tinashumor/humor/corpmemo.html)

SEMAT, Controversy, and Pragmatism

Thursday, June 17th, 2010

Leaving aside the question of the need for a general theory of SE, I think the idea of a meta-kernel is very useful. It seems to me that different organisations are going to configure their software engineering practice differently based on the nature of their business. If there is some theoretical underpinning to the idea that one size does not fit all organisations that’s a good thing. Let’s assert that this meta-kernal includes the following placeholders [opportunity, way of working, requirements, system, architecture, team, governance]. If I were to treat those placeholders in the kernal as holes into which I could mix and match practices, I would have something useful. Here’s where my thinking comes from…

I was watching a Jeff Sutherland video at (http://www.youtube.com/watch?v=9y10Jvruc_Q) where he talks about Scrum and Google building Adwords, and it seemed to me that the way they did that made sense for them. Not everybody is Google. We might classify Google as an ‘information company’, and Microsoft as a sealed package company, and PatientKeeper as a ‘managed service’ company. But that still leaves lots of organisations where software is not what they fundamentally offer, what they ‘do’, what they sell. So it stands to reason the way those organistions organise themselves to build software is going to be different. Not everybody is going to be an XP shop (clearly), not everybody thinks Scrum will do everything.

So with a meta-kernal if Bank of America want to combine [RUP, use cases, Java, MVC, cross-functional teams, Scrum, PMBOK] then why not? There are a lot more organisations out there like banks, insurance companies, stock brokers etc. manufacturers, wholesalers etc. who are never going to be cutting edge Agile houses, but maybe they can use bits and pieces from different practices that work for them and maybe that would be OK. Why not? Now that would make a meta-kernal really useful and whether or not it provides the foundation of a universal SE engineering doesn’t matter for this application because it provides a universal notion of how different practices in different fundamental areas of software engineering concern can be combined.

If you find this interesting read ‘Agile and the Universals of Software Engineering’ (an earlier posting…)

Humpty Dumpty putting it all back together again

Monday, May 24th, 2010

Say you are a Scrummaster walking along, minding your own business, and you come across a pile of user stories lying on the pavement. You pick the first one up, then the second one, then the whole pile of them and get yourself a stick of glue and begin to paste the stories together, hoping to get a view of the whole that ties all these stories together.

Or, imagine for a minute that these user stories are instead pieces of a jigsaw puzzle and it’s your job to make them into a big picture. The problem is that somebody has lost the box – you don’t know what the finished picture is supposed to look like. Suppose you use up all the pieces, but there’s something wrong. The person who lost the box, also lost some of the pieces.

What I’m talking about really is stories at different levels of decomposition; the hierarchy of stories, the project, release, iteration, of stories. If we haven’t got the project stories, we can’t make much sense of the lower level stories because we are unsure how the parts are supposed to hang together. If we have the project stories, that’s a different thing because we can break them down into lower levels that can actually be built in an iteration.

So we are agreed then that project stories break down into lower level stories, and it’s pretty straightforward to do that, but it’s still really important to make a picture of how those stories are related (their hierarchy of decomposition), because if we don’t know that, it’s just like having a smashed up humpty-dumpty at the bottom of the wall, and putting him back together again is just not going to happen.

Café Culture

Monday, May 24th, 2010

Remember when they changed the alcohol laws and expected the British would start drinking like our European neighbours? Have you been into your city centre on a Friday night recently? It didn’t happen. It might happen but cultural change takes a long time.

If we are going to wait around for fundamental business cultural change before Agile can work it could be a really long wait. People will lose patience, the next big thing will come along, and everybody will jump on that bandwagon heading nowhere fast. No, no, no, there’s too much that is really good about Agile and what works – works, so let’s leave it alone. What I’m talking about is Agile Requirements – that’s rigour around user stories. Stories don’t belong in Delivery, they’re an input to Delivery, they’re the ‘requirements’, and they belong to the business. Yes, this goes against the status quo – all well – that’s what makes for a good conversation – right?

Does this violate the Agile principle of ‘cross-functional teams’. No, I’ve already said that what’s in Agile Delivery works and stays as it is. I’m just saying that it isn’t efficient to show up on day one of a Scrum for a planning meeting and expect all these expensive people to start writing stories from scratch, or worse yet, trying to make sense of a big mash-up of stories and fragments before they can get to work building something. It’s demoralising and it’s counter-intuitive. It doesn’t work. You show up on day one, you want some good quality stories to get your teeth into. That’s common sense – maybe not common practice, but it’s common sense.

I’m going to make the distinction between Agile Requirements(AR) and Agile Delivery(AD). So, to be clear, part of the story telling has to happen outside of AD. Once the iteration is underway, the two work together, but AR outputs stories and AD takes them as an input. This has a lot of ramifications – and they’re all good.