Inbound & Outbound marketing

Its nearly the end of the year, I’m about to close one Blog archive and start another - don’t worry, this means nothing for readers, its part of my admin. But it does mean that I put behind me all those half written blog posts, and single line ideas, that have been building up during the year.

Before I do so though, there are a couple of days to quickly get important backlogged entries out!

Two weeks I blogged, not for the first time, about Product Manager (Product Management an open secret, a differentiator). When I talk to people about Product Managers I often find myself in a conversation about marketing. Clued up people realise that good Product Management is, in part, a marketing function, others are surprised. They think marketing is about advertising and sales.

It is important, very important, to differentiate between the two sides of marketing: Inbound and outbound. So, for the record, I want to record it:

Outbound marketing: is the marketing most people think of when someone days “marketing.” This is about letting people know you, and your product, are here. Its advertising. Its public relations. It is generating sales leads. It is improving awareness. You get the picture?

It is called outbound because it is from you and your organisation to the wider world.

Inbound marketing: is from the wider world (customer, potential customer, competitors) to your company. It is about bringing that information inside and then acting on it. It is about building the products your customers want to buy. Get it right and sales should be like a knife through butter, people want your products.

In software companies, and other tech companies inbound is largely the role of Product Management. Product Marketing is about outbound. Although Product Manager is the usual job title some places call this role an Architect, others Programme Manager, and occasionally Project Manager. More often or not it is just absent.

Most companies realise, sooner or later, that outbound marketing is needed. Unfortunately, in all too many companies inbound marketing does not exist. Or inbound is “what the sales guy says the customer wants.”

As much as we love sales people (after all, they bring in the stuff that pays us) they are not the best people to decide what goes into a product. The reason why they are good at selling is that they get over customer objections and sell the product. This means the customer, the next customer, the next sale, is king. What the next customer wants isn’t what every customer wants.

Lets make this simple: if you are running a software product company and you don’t have a Product Manager then get one.

ACCU 2011 Conference registration open - beat the VAT rise

Just in time for Christmas, that special present for someone you love...

Buy them a place at the ACCU Conference in April.

If you live in the EU you have an very special reason to buy in the next few days: the UK is increasing the VAT rate so the price is going up on 1 January.

If you really want to save money, and you are not already an ACCU member then join the ACCU now, and immediately book the conference. It is cheaper, honest; no, its not an accident, it is meant to be like this.

I’ll be there, in fact I’m speaking, I have two sessions, one on requirements and one on patterns.

(Twitter tag for this is #accu2011)

Dialogue sheets, retrospectives and quotes (Send me your quotes)

Know any good quote about software development? Agile? Lean? Teams? Code? or anything else in this space?

I’m working on a little project and I need some though provoking quotes so please send them over - leave a comment here, e-mail me (allan at allankelly.net) or Twitter me (allankellynet).

Why?

Well, I’m working on a little project for retrospectives I’ve been dreaming of for a few year and I need some thought provoking quotes.

There are two problem I see with retrospectives - OK, there are other problems but there are two I think I can do something about. (And none of these problems undermine the reason for doing retrospectives or the value, just fly-in-the-ointment stuff.)

Firstly, retrospectives need a facilitator. That might not sound like a problem but ideally you want the facilitator to be a) experienced, b) impartial, c) available. Sometimes its not easy to find that person.

Second, I hear of teams who hold regular retrospectives but the retrospectives because boring, they go over the same ground again and again. To be effective, to get new insights they need jazzing up once in a while.

One way to resolve both problems is to use an outside facilitator once in a while but that needs organization and, most likely, money.

So, what if you could have a retrospective without a facilitator?

Over the last few years I’ve been experimenting with a technique called a Dialogue Sheet. Both in training and conference sessions I’ve used this to facilitate discussion. For more about dialogue sheets see my website with examples from XP Day, SPA and “Lean into Action” at the Agile Lean Exchange last month.

Now I’m working on a Retrospective Dialogue sheet. The idea is a team us this for a facilitator-less retrospective.

I hope to have the sheet ready by New Year and then I’ll be looking for some guinea pigs...

And the quotes: these get placed around the dialogue sheet to provoke thought and reflection.

When I’ve got this working I hope to allow you to download these sheets from my website or order printed versions directly.

Product Management an open secret, a differentiator

At the Skills Matter Agile Lean Kanban exchange the other week someone - sorry I missed you name - told me about a report from the BBC on Product Management. It turns out the report is from a branch of the BBC I didn’t know about, “BBC Academy” and it entitled “The State of Product Management 2010.” Its well worth reading if you have an interest in Product Management or the UK software development scene.

Although I’ve not blogged about it for a while Product Management is one of my passions.

Think of the development team as the beating heart of the work effort. Someone has to keep the blood flowing, someone has to keep the arteries clear and make sure the right requests for work can channelled to the development team.

This is a role. Someone needs to do this. Someone needs to understand customers and be in a position to prioritise. And someone needs to be able to have ongoing conversations with customers, developers and everyone else.

This is not a document, attempts to do this with a document makes things worse. Documents don’t have conversations. Documents are static.

One of the reason why Silicon Valley companies are so successful is that they understand this. In Silicon Valley there is a well developed role called the Product Manager. This is the person who looks at the customers, understands their problems and needs, looks at the market and a whole bunch of other stuff, and this person decides what is needed for a successful software product.

I point to Silicon Valley because certainly in Europe, and I suspect in much of the rest of the USA, this role isn’t so widely recognised.

This role doesn’t exist in corporate IT. Here the Product Manager’s cousin the Business Analyst fills a similar role but in a very different way. However, there is change afoot here, stay with me.

Here in the UK I find I have to explain this role to clients again and again. They make four common mistakes:

1. They assume the development team just know what is needed. Sometimes they do, sometimes they don’t. They may get luck once but can you rely on luck the second time? Third time?
2. They assume that the Project Manager knows. Again this is wrong, Project Manager training is about delivering a defined project to a date within constraints. It is not about understanding customers. (True there is overlap but Project Managers training is different.)
3. Experience IT Managers see the need and appoint a Business Analysts. This is the right thing to do when you are a corporate IT department, or if you are writing bespoke software for one customer but, if you are trying to create a product to sell to many customers it is the wrong choice.
4. Managers assume it is obvious, or that they, the “managers” know. If they are Product Managers or have been Product Manager they might be right. Even if they do know what the customers want someone has to explain it to developers and be on hand to answer their questions. Senior Managers just don’t have the time.

So its good to see the BBC highlighting this role. The description in this report is very media centric but it is recognisably the Silicon Valley Product Manager role. There are some good case studies in the report.

As I said, over in the corporate IT world this role doesn’t exist because customers are captive. One of the key aspects of the Product Manager role is understanding what customers (who have a choice) will pay for. In the corporate IT world this doesn’t exist: you get what you are given. So the BA role is similar but different. (There are other difference but they are for another day.)

(Interestingly several of the Product Managers quotes in the BBC report state they have Business Analysis backgrounds.)

The thing is: Business Analysts need to become more like Product Managers because more and more corporate IT departments are creating systems for external customers who do have a choice.

For example, 15 years ago just about all the IT created by travel companies was for their own use. Today travel companies have customer facing IT systems which can both win and loose the company sales. Online offerings are part of the buying experience, part of the customer experience and a potential product differentiator.

Even though the Product Manager role is not as well understood as it should be it is becoming more important. For those who get it Product Management is a potential differentiator.

Return to Requirements @ Skills Matter

I’m presenting a Skills Matter In the Brain Session this week, entitled “Return to Requirements.”

The key thing about this presentation is that it give a very very brief overview of the “Agile 10 Step” which is the model I use to discuss requirements in Agile work.

It is Tuesday 14 December, 6.30pm to be exact. Its free but you need to registration is required.

Salami Agile

More than one software development team has encountered the situation when the team want to be more “Agile”, the organization and management might even be asking them to be more “Agile” but, there are still many “requirements” in a big requirements document and the expectation is that all these will be “delivered.”

Ideally I would not set up and Agile development like this. Yes I’d set a few requirements to seed the first iteration but I would take a more goal directed approach. I’ve written about this elsewhere - see Time for Goal Directed Projects.

Basically Goal Directed means: the team have a goal, the team will determine what needs doing (requirements) and do it (implementation) as part of the same project. The team will be staffed with everyone they need to do both sides of the work (BAs, Developers, Testers, etc.) and will be judged by their success on reaching the goal. They will not be judged on how many features they implemented from some big initial set.

But, as I started by saying, some teams do have a shopping list of things they are expected to deliver and they will be judged on how many of those items are delivered and when.

So what do they do?

This is where Salami Agile comes along.

Think of the Big Requirements Document as an uncut piece of Salami. Someone on the team - preferably someone with Business Analysis skills but it could be a developer, project manager, or someone else - needs to slice the requirements into thin pieces of salami (story) for development.

There is no point in slicing the whole salami in one go. That would just turn a big requirements document into a big stack of development stories. The skill lies in determining which bits of the document are ready (ripe) for development, which bits are valuable, and which bits can be delivered independently.

Some slices of salami will need to be thicker than others but thats just the nature of the world. Over time, with more skill at slicing salami it will improve.

Ideally, the pieces of salami are delivered to the customer early, and over time they start to realise they don’t need some parts of the requirements document, some salami can be left unsliced and simply thrown away. Other pieces of salami will be cut and then thrown away. Thats not failure that’s reducing the work and is good.

And some requirements which were not though of can be easily incorporated. To stretch the analogy, you switch from German Salami to Danish Salami and back again if you so choose.

I imagine some readers will recognise this development approach, good. Now we have a name for it: Salami Agile.
(Picture from André Karwath on WikiCommons under Creative Commons Attribution-Share Alike 2.5 Generic license.)

Agile in Cornwall

As I’ve mentioned before, one of my current projects is to help companies in Cornwall adopt Agile software development. The programme is bring run under the Grow Cornwall umbrella by Oxford Innovation.

Next Thursday there are two open to everyone sessions to introduce Agile to companies in the Cornwall area and talk about the work we are doing.

If your interested you need to register at MeetUp - “Agile in Cornwall - Meet the Experts.”

Three plans for Agile (long version)

As noted in my last blog entry RQNG has published my description of Agile planning using Iteration plans, Release Plans and Roadmaps. I’ve added a little bit to this an produced a longer version of the same piece - it only adds about a page.

Three Plans for Agile (long version) is now available on my website.

Three Plans for Agile on RQNG

RQNG has published one of my articles entitled “Three Plans for Agile”. This looks at the role of iteration plans, release plans and roadmaps, and how the three fit together.

I have to say thanks to Jon Harley, we had an e-mail discussion months ago which was the seed of this article.

After writing this I discovered (I’d like to say remembered but truly, I’d forgotten) that I actually blogged about this early last year as part of my Project Plans mini-series.

Reverse-Tolstoy continued - from Agile EE

In my last posting I suggested thatif Leo Tolstoy worked in a corporate IT department the opening lines of Anna Korenina might have read:

“Unhappy corporate IT departments are all alike in the same unhappy way; all happy departments are happy in their own way.”

I call it Reverse-Tolstoy (because he actually wrote the reverse, well kind of). I want to continue that rant with some other ways corporate IT departments repeatedly mess up.

Belief that process change is it
I wrote in my previous entry that corporate IT departments do not focus enough on the technical side of Agile, specifically they don’t think about code quality and technical practices. Part of this is caused by a belief that process change is the change they require. That is to say, that changing the process they use, whether that means “Agile” rather than “Waterfall”, or Scrum over ISO-9000, or Kanban over ad hoc, or what ever, well, thats the change they need.

Such a view ignores the technical side of change required. As I’ve said before, and I’ll say again, I don’t believe you can be Agile if you don’t address the quality issue. I also believe that the best place to start your Agile change is with the quality improvement (thats a TQM, ISO9000 or Six Sigma quality programme by the way).

No customer involvement
For these IT departments actual, paying, customers are a long long way away. This is changing a little but most of the customer they have are internal, i.e. other parts of the business. These customers have little involvement in the development of IT system. Indeed, you will frequently be told that they want minimal involvement.

The internal customers have an image that they can hand over and idea, sign a requirements document, and leave IT to get on with it. They might get involved in some acceptance testing but they don’t want to hear about it before then.

I think this view has been encouraged by corporate IT. I think IT as an industry has trained customer very well, customer now believe if they just write it down, hand it over then it will be. Kind of double-think really because most customers have also seen IT failure. However, they think its “IT failure”. The idea that they, the “customers”, might be part of the solution is strange to them.

Instead they cling to....

“Long” UAT cycles that are separate from development
UAT, User Acceptance Test, the thing that the “business side”, the people who want the software do to ensure you deliver what they originally asked for. Having thrown it over the wall, having waited, having complained the “customer” wants make sure you deliver what they asked for. So the have a user acceptance test cycle.

Unfortunately this normally comes too late in the day to make a real difference, and, real “users” don’t actually want to be involved. So you often find UAT is carried out by dedicated UAT testers who don’t actually do the customers job.

UAT ends up being just another test cycle. All too often it is where real testing takes place, by the time the software reaches UAT it is still buggy. Rather than being about seeing if the users like the software UAT is about finding bugs.

UAT is normally one of those “no go” areas when you start talking Agile. Frankly, the business doesn’t trust IT enough to believe they will deliver anything, let alone that it is of high enough quality or actually meet customer needs.

Personally, I think you can abolish UAT, but I don’t want to try until I’ve fixed the quality problems in the team and got the basics of Agile up and running. But during this time people keep waving big red UAT flags warning you not to mess with UAT.

This is another example of....

Adherence to existing processes and constraints
All the companies have existing processes in place. Many of them are simply “off limits.” You get looked at as if you are mad when you suggest they annual planning cycles aren’t Agile, or time tracking systems are pointless.

The trouble is, too many of these “off limits” areas and you end up with no change. One big off limits process is the time tracking system....

Time tracking systems - measuring inputs not outputs
Nether mind that time tracking is an act of fantasy on a par with Arthur Conan Doyle, or that it wastes a lot of people time and even more energy one thing that is never on the agenda for change is time tracking.

All these big companies seem addicted to measuring inputs rather than outputs. They know the cost of everything and the value of nothing. Or rather, they think they know costs but really the time tracking systems are so hopelessly inaccurate they don’t reflect what is actually happening.

Time tracking gets really dirty when resources are not visible, that is, when they are offshore. Manager worry that their teams aren’t working hard enough but my experience is the teams are working to hard and just not logging all the hours - the late nights, weekends. The offshore staff thing they are “doing whats needed.” Unfortunately when this short term fix gets ingrained into regular practice its a big problem. It is also a sign, and the cause of, a lack of trust.

SWAGs “High level estimates”
Large companies like to get early “high level” estimates, sometimes called “Seriously Wild Assed Guess”. The idea is to get a ball park number for initial planning and refine it later one.

Trouble is, they don’t. The SWAG is it. It is treated as commitment and people are expected to honour it. In the worst cases the SWAGs appear to work, but thats really because the time tracking system is such a fantasy-land.

Quick Test Pro and Quality Center
All these big messed up IT departments use Quick Test Pro and Quality Center. I’ve looked at these tools, albeit a little, and my conclusion: Emperor’s New Clothes. There is nothing there.

So why so many test groups are stuck on an old version I don’t know.

Message: Save money, throw them out, get FIT, Selenium, JUnit, etc. The best things in life are free.

I look forward to the day when writing a test script in a natural language like English is a criminal offence you can be sent to jail for. If you are going to write a test script then automate it. Precise English takes just as long to write as code. (Even then it isn’t so precise.)

Not really knowing why they are doing “Agile” - seems to be the fashion of the day
At the end of the day most of these corporate IT departments don’t actually know why they are trying to be Agile. I think if they were to really think hard the answer would be Fashion. Yes it sounds good but so did Business Process Re-egineering, ISO-9000 and offshore outsourcing.

Most of the staff inside the companies regard Agile as just the latest change programme. They know it will pass in time. Yes there are some very enthusiastic people in the company, and some highly paid consultants too but that was the case with BPR, ISO-9000, and every other change initiative.

The trick is: keep you head down, look like your going along with it and wait for the next fashion to replace this one. In other words: Don’t want to rock the boat too far.