Where has the Product Owner gone?

June 24th, 2010

The product owner in Scrum is a very busy guy/girl. S/he’s got to:

  • Define features of the product (or desired outcome)
  • Decide release date and content
  • Ensure profitability
  • Prioritise features/outcomes
  • Adjust priorities
  • Accept or reject work

Does this person really exist? Is it possible that somebody can be found to do this job; that has the subject matter expertise and the authority to make big decisions all wrapped up in one person? That’s a busy person. And isn’t it likely that somebody like that is too busy to participate in the Scrum team on a daily (insert time period you prefer here depending on how ‘Scrummy’ you are) basis?

So we come on to the subject of the proxy product owner. Where is this defined in Scrum? Roman Pichler at the Aglie Alliance writes:

Using a proxy product owner is an attempt to superficially treat a systemic issue. Rather than employing a quick fix, organizations should address the underlying issues. This might require freeing up the product owner from other obligations; colocating the product owner, ScrumMaster, and team; or even finding a new product owner.

http://www.scrumalliance.org/articles/168-common-product-owner-traps

So is this Product Owner a logical role or a physical role? I think it’s supposed to be a physical role i.e. one person does it. I was talking to the owner of an Agile consultancy recently, and he said he’d never met one. I’ve never met one either. Sometimes I get the feeling that Scrum dictates what the world should be like and the world struggles to fit the definition and that’s frustrating. Which is flawed, the world or the Scrum definition?

What was wrong with Project sponsor, Responsible owner, Subject matter expert and Story Teller? After all, these are the competencies the Product Owner is being asked to exhibit. No wonder it’s hard to find this guy/gal. Maybe s/he’s a unicorn.

Tags: , ,
Posted in Evolutionary Agile | 2 Comments »

Another View on the Agile Manifesto

June 23rd, 2010

Agile as a term in software engineering derives its meaning from the Agile Manifesto. The Manifesto makes four simple points listed below.

‘We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.’

Or, a slightly longer version:

  • Process is important, but not as important as people working in effective teams.
  • Documentation needs to be appropriate and it needs to make the delivery of working software more efficient, because working software is what is important.
  • If you have to rely on a legal contract, the relationship has probably already failed, so put a lot of effort into working with the customer as a partner.
  • Things change, people change their minds: deal with it, rather than getting hung up on a plan that is imperfect

This is just a way of turning the original points around to give them added emphasis. It helps me to gain greater clarity anyway :-)

Tags: ,
Posted in Evolutionary Agile | No Comments »

Scaling Scrum to the Enterprise and the Challenge of Dilbert

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)

Tags: , , , , ,
Posted in Evolutionary Agile | No Comments »

SEMAT, Controversy, and Pragmatism

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…)

Tags: , , , ,
Posted in Big picture, Evolutionary Agile | No Comments »

Agile and the ‘Universals’ of Software Engineering

June 17th, 2010

Different kinds of organisation build software differently. Why might that be? Maybe it’s true that for some organisations Prince2 or PMBOK, or Scrum are absolutely the right choices. Maybe for a certain organisation .net is the way to go or Java, or Ruby on Rails. Perhaps your organisation captures requirements in natural language, or with use cases, or in user stories and that works fine for you. Probably every organisation in the world uses software, but for some software is the centre of their universe and for others it is a support function.

A company like Microsoft is likely to have a very different way of building software from a government department, or from a 3rd party supplier of software who wins their business in open competition. One way of describing organisations based on how they use software is presented below:

  • Sealed Packaged solutions e.g. Microsoft, Apple
    Build software products and sell them.
  • Unsealed Package solutions e.g. Siebel, SAP
    Build software products, sell them and configure them
  • Managed services e.g. PatientKeeper,
    Build a single software service and sell access to the service.
  • Information provider: e.g. Reuters, The Guardian, Google
    Build and platform that gives access to valuable information.
  • Professional services, (incl. Government, Manufacturer/Supplier): e.g. Aviva, Barclays, Lloyds of London
    Provide banking, insurance, order processing, manufacturing support, government services etc. and use IT to support the business.
  • 3rd party supplier: e.g. mPhasis, Tata, Logica
    Build software and services on behalf of other professional services or information providers.

How core software is to what the organisation does is going to affect the way an organisation configures itself with respect to software engineering.

The ‘Universals’

If you want to build software, what are the kinds of things you need to worry about? Have you got all the bases covered? That’s the question the group ‘Software Engineering Methods and Theory’ (SEMAT) have been asking themselves. SEMAT aim to come up with a design for a meta-method-kernel. This is perhaps not a fundamental theory of software engineering [1], it is however a useful thing to have [2] because everybody building software should have thought about the tasks they are going to be faced with and can at least make a rational decision on what practices they should adopt. The decision they make will be affected by the type of organisation they are and the centrality of software to their core mission.

SEMAT haven’t finished their work yet, (and perhaps they never will!) but we don’t have to wait to propose one view of what that kernel of software concerns might look like.

Figure 1: A version of the Universal kernel of software engineering concerns

The kernel in figure 1 is a collection of placeholders and it is up to the organisation to put some practices into the holes. It can be argued that there will always be something in the holes, even if the something is actually an ad hoc practice. Having watched Jeff Sutherland talk about the work at Google to build Adwords, one is left with the impression that Scrum pretty much does it all [3].

Figure 2: a populated kernel as Jeff Sutherland might have visualised it working on Adwords.

That could be absolutely fine for Google, because they are pretty good at building software and they have access to their product owners on a daily basis. The culture of Google is to have few managers and it is led by engineers. Not all companies are like Google though and therefore there is no need to copy them, because the way they do things may just not be right for the way you do things.

Consider a different kind of organisation, such as an insurance company. This company spends a lot of money on I.T., they used to do it in-house and now they’ve outsourced it to Eastern Europe. They have a Programme Management Office (PMO), they have people who want to manage risk, and are interested in ‘quality’. It’s not my job as a person interested in methodologies to tell them they should change before I can help them build better software. I can work with them to demonstrate that maybe there is a better way and if that is successful they can choose to change themselves.

In the meantime it’s perfectly possible for them to take advantage of the kernel of concerns and define a set of good practices that work for them to improve their software delivery.

Figure 3: a populated version of the universals kernel that would be appropriate for an organisation where software was not its primary product.

In Figure 3, our imaginary insurance company has chosen a set of practices that suits it, its culture and the degree to which software is integral to its business. One of the benefits of this way of visualising a software engineering practice is that it makes it easier to ‘hot swap’ one practice out for another without disturbing the others. This is the familiar concept of ‘encapsulation’.

My particular areas of interest in this topic include:

  • Opportunity: Demand management, Ideas management, and Benefits Analysis
  • Requirements: Agile Requirements Practice
  • Way of working: Unified Process lifecycle
  • Governance: PrinceLite www.princelite.co.uk

References:

[1] ‘Why We Need a Theory for Software Engineering’, Dr Dobbs, Jabobson I, Spence I, [2009] http://www.drdobbs.com/architecture-and-design/220300840;jsessionid=RZLXNZ2D4154PQE1GHOSKHWATMY32JVN

[2] ‘A Detailed Critique of the SEMAT Initiative’, Cockburn, http://alistair.cockburn.us/A+Detailed+Critique+of+the+SEMAT+Initiative [2009]

[3] Scrum Tuning: Lessons learned from Scrum implementation, Jeff Sutherland, [2006] http://www.youtube.com/watch?v=9y10Jvruc_Q

Tags: , , , ,
Posted in Big picture | No Comments »

Is Agile Broad Enough?

June 11th, 2010

It is widely accepted that Agile delivery demonstrateably adds value to software teams and their ability to bring software to fruition. There is however a question around whether Agile can achieve its full potential in the face of cultural resistance within the wider enterprise. For some there is now the acceptance that IT has the potential to be more than a cost burden; it is actually an avenue to compete more effectively in the market. IT is a strategic tool where projects with quantified business value deliver everything from streamlined internal processes to new customers through social networking sites. The better able the enterprise is in harnassing IT the better it will prosper, however it is not easy and they achieve varying degrees of success.

Set against a wider context of the end-to-end business process, actually delivering some working code comes far downstream. What needs to happen first? First ideas need to emerge in the organisation, gain momentum, become scoped, costed and valued and then, if all goes well, the initiative results in working system.

Given the project delivers a working service, we would be interested in a retrospective aimed at measuring success. For instance, certain assumptions were made regarding how much value the project would bring and how much it would cost to bring to fruition. We want to know whether it was ultimately worth taking this project forward once it has had a chance to ‘bed down’ because that information is valuable. Ideally a cycle can be established where the assertions and outcomes of initiatives are tested so that they may inform future estimation activity resulting in the ‘go/no go’ decision that governs all intiatives becoming more accurate. In this scenario, the estimates of future projects (cost and value) are compared with the resulting outcomes ultimately leading to the enterprise fully directing the IT function and reaping maximum competitive advantage.

Tags: idea management, governance, PMO, Programme management, Project management, effort estimation, value analysis, agile evolution

Tags: , , , , , ,
Posted in Big picture | 1 Comment »

A New Definition of ‘Epic’ 2

June 4th, 2010

This is the second post on a new definition of ‘epic’. The first post is all about types of story. If you haven’t read that first post, it might be a good idea to read that first. This post looks at the other elements (not stories per se) that crop up as inputs to requirements.

On day one, before running any workshops or conducting any interviews, you have to become familiar with the documents that have already been written. There might be reports, or project mandates, or business cases to read, or whatever. A good approach is to read the documents and start creating index cards for each salient point you encounter. Then it’s a question of making sense of them, categorising them, and creating a requirements hierarchy. Let me be absolutely clear on the point that I am not advocating a big requirements effort upfront reminiscent of ‘waterfall’. I’m just taking the pragmatic approach that whatever you do going forward, there is a need to make sense of what’s already gone on. This can be termed ‘traceability’. How can you demonstrate that what you propose in a couple of weeks time (a nicely groomed backlog – filled with implementable testable functional stories) satisfies all the inputs that have already been given?

Non-story inputs include:

  • Constraints: a condition that must not be broken
  • Non-functional requirement: a condition that must be exhibited
  • Business rules: related to a particular story (functional behaviour). Implemented as an if…then… condition. Often related to ‘state’ of a business object
  • Implementation tales: someone’s suggestion as to how the solution will be implemented
  • Acceptance criteria: related to a particular story (functional behaviour). A test that can be run to determine whether a story concludes in the manner desired

Even if you are starting the project from the outset, not everything people tell you is going to make a good candidate story. Take ‘security’. Say somebody tells you the system needs to be ‘secure’. This seems like a statement of the obvious; of course the system needs to be secure. Are you going to write a story:

As a data specialist

I need to ensure our customer data is secure from outside hacking and mis-use

So that data is not stolen and customers compromised bringing bad publicity on to the organisation

Clearly it is possible to describe ‘security’ as a story (as demonstrated above) but is it the best way of articulating the need? Is it the best use of your time? There are no hard and fast rules about categorisation, but there are guidelines (although there remains ambiguity and we can argue about it). Again though, remember we are ultimately aiming to get that well-groomed backlog created, and that means defining stories the programmers can implement as functional behaviour. Nobody is going to use your new system and come to it with the express objective of ensuring their data is secure. They are just going to use it with the expectation their data is secure. The system needs to function without breaking the rule that data is secure, so it’s natural to see ‘security’ as a constraint; behaviour that is not violated while the system is in use.

Figure: A new definition of a ‘project epic’.

Tags: , , , , , , , ,
Posted in Big picture | No Comments »

A New Definition of ‘Epic’?

June 2nd, 2010

There are five different types of ‘story’ the master story teller will deal with. The first two are Enterprise stories and Back stories which are related. These types of ‘story’ are discovered by the story teller when the project is already ‘in-flight’ and the job is to demonstrate traceability. Typically the first two types of story are not told in the classic format of (As a… I need to… So that…). They may be in any format, and it is of limited value to convert them into the standard format. The story teller should consider these types of story as a source of ‘reference’.

Enterprise story: (1) a management aspiration that is not project specific e.g. ‘Recapture the number one position in the market within 12 months by customer satisfaction and sales revenue’. ‘To reduce maintenance costs by 15% over the financial year’. ‘To increase expenditure on frontline services by 12%.’ ‘To reduce customer ‘churn’ by increasing customer satisfaction. (2) A ‘command’ from senior management that is project specific. ‘The new content management system (CMS) will use templates’, ‘The CMS will delegate content management to content owners i.e. without the need for technical resource’.

It is unnecessary to write enterprise stories in the classic user story format (As a… I need to… So that…). Enterprise stories are not directly implementable in code.

Back story: a back story is an input to the requirements gathering process that has been uncovered by the analyst during investigation of pre-existing requirements artefacts. Back stories are similar to the second definition of Enterprise stories, however they do not originate from senior management i.e. ‘The new content management system (CMS) will use templates’ could equally be a back story if it is discovered in a document written by non-senior management. The reason for separating out back stories from this type of enterprise story is to demonstrate traceability to different audiences in the organisation.

There are three types of ‘classic’ user story, all of which are hierarchically related.

  • Project story
  • Release story
  • Iteration story

Project story: states the goals of the project from the perspective of the individual users who will use the system under consideration. Project stories are the basis of user acceptance testing. Project stories describe the end-to-end navigation of a particular business process. Project stories satisfy enterprise stories. Project stories are not directly implemented in code as they are satisfied by the aggregation of release/iteration stories.

—

As a customer

I want to explore opportunities

So that I can take advantage of new pricing plans

—

As a customer

I need to get answers to my questions

So that I can get the most out of my service

—

As a content owner

I need to provide answers to customer questions

So that customers can get answers to their questions

—

Release story: a functional decomposition of a project story that represents value to the customer/users in a standalone fashion. Collectively release stories satisfy project stories.

—

As a content owner

I need to create new content

So that information informs customers about new pricing plans or answers to questions, or general information of value to customers

—

As a content owner

I need to maintain existing content

So that information is relevant and current to inform customers about new pricing plans or answers to questions or general information of value to customers

—

As a content owner

I need to find relevant and related content

So that I can maintain the information and avoid creating duplicate or misleading messages

—

Iteration story: a functional decomposition of a release story that is of a size that it can be delivered in a single iteration. Collectively iteration stories satisfy release stories.

As a content owner

I need to find all content that relates to pricing plans for a given mobile device

So that a summary can be returned and the relevant information displayed.

—

As a content owner

I need to be able to modify the text on the page relating to prices

So that pricing data can be modified

—

And when you put this work together you get a graphic representation that looks like this:

The story teller will encounter other kinds of inputs to the ‘big picture’. It is tempting to consider all stories, all types, and all other inputs, when you put them all together, as being the ‘epic’. Unfortunately, the word ‘epic’ is already used in the Agile world to mean ‘a story that is too big’. This is unfortunate because there is a shortage of suitable words, and epic is such a good one it’s a shame it is used for such a non-specific concept. Instead, you can use the term ‘big picture’. The epic/big picture includes the story types we’ve just looked at plus the following:

  • Constraints
  • Acceptance criteria (related to stories)
  • Business rules
  • Implementation tales
  • Non-functional requirements

The story teller has to know how all these inputs fit together. This is the subject of a later posting though. I’ll also be publishing graphics and spreadsheets that show how these elements all fit together so you can tell the epic, show the big picture to other people in the team in readiness for the first and subsequent iterations. Stay tuned.

Tags: , , , , , , , ,
Posted in Storytime | No Comments »

The Baby and the Bathwater

June 1st, 2010

Every now and then people get so fed up with software failure they reckon it must be a systemic problem and they throw the collective knowledge in the bin and start again. This is the hunt for the silver bullet. The magic weapon to slay the vampire. This happened with use cases when user stories came along. It’s a shame. It’s lucky that use cases got stuck in the U-bend, and somebody used the plunger to suck them back up again.

The problem is not, and never has been, with developers being unable to cut code. Programmers do a good job with what they are given. It just happens that what they are given (the software requirements – user stories, whatever…) aren’t very good. Programmers don’t bother going back to the business and asking for something better, because they don’t get it, so they become resigned and get on with doing the job as best they can.

Agile delivery works fine. But user stories can be just plain silly. Just because it’s hard to define a good software requirement does not mean you don’t have to do it. If a user story isn’t properly fleshed out, you will find yourself trying to get to the details in programming time, not in investigation time – and that is wasteful and very expensive. It is going to lead to a lot of frustration.

‘Make things as simple as possible, but no simpler’. I wish I’d said that, but I’m just quoting it. (Apparently it wasn’t Einstein.) User stories with no structure, user stories that have no sense of wider context, are just too simple to be relied upon in anger. Hey, it’s not the delivery team that’s broken, it’s the requirements team. It always has been, and it still is.

User stories are a technique that in the hands of a good analyst are going to give the business a nice warm feeling that they are participating in the process. That’s a good thing. That’s a great thing. But you still need the analyst. This is not a process that can be de-skilled. It just can’t.

As Alistair Cockburn puts it “it’s much easier to write user story tags on index cards [then apply use cases] and let the project blow up later.” Agile project fail all the time. Practitioners claim failure is a kind of success. No, failure is failure. There’s no silver bullet, that’s true, there’s a whole box of silver bullets, and they only work when they are applied in a coordinated manner. Read: http://alistair.cockburn.us/Why+I+still+use+use+cases

Tags: , , , ,
Posted in Big picture | No Comments »

Humpty Dumpty putting it all back together again

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.

Tags: , , ,
Posted in Storytime | 1 Comment »

« Older Entries