This is my personal blog - stuff not directly connected to my work goes here - some of it's a little spicy, so watch out for heartburn. Of course if you're lucky you'll find something valuable in the mix of product development, Agile development, innovation, technology and marketing that I write about.
Like most everyone else practicing automated unit testing the developers at Elcom Technology have the issue to deal with of how to handle dependency injection – that is the exposure of a given object’s dependencies on other objects outside of the object so that the calling object can be made responsible for acquiring those dependent objects. In general this is most easily done by exposing said dependencies in the object’s constructor as required parameters – thus ensuring that the calling objects knows it needs to supply them when new'ing the object. So far, so good.
Recently (as of CM v7.2) we have introduced the Elcom.API library in an attempt to use the adapter pattern to present a more cogent, safer and easier to use interface to our CommunityManager.NET web CMS product. This is all well and good, but it means that to ensure testability we now have chains of dependencies throughout our application code – and declaring something a dependency of object A, when it is required by that object only to call object B, which then only needs it to call object C, creates some very smelly code.
Clearly we needed a dependency injection framework of some sort, but what should we use? Like Uncle Bob we didn’t want our DI framework to leave code smell throughout our projects. Well, we already have an object with all static/shared methods called Current. We use this to give an easy way of accessing some current state items, such as:
Dim a = Current.Configuration.ConnectionString
Dim b = Current.Configuration.EncryptionSettings
Dim c = Current.Configuration.ShortDateFormat
Dim d = Current.HttpContext
Dim e = Current.UrlId
Dim f = Current.User
Dim g = Current.UserId
Now we want to expand that to offer this sort of syntax to give easy access to services/repositories:
Dim myContSvc As Content.IContentService = Current.Service.ContentServiceGet()
That would give a simple way for object B to instantiate an IContentService without needing to declare it as a dependency to object A (but object C should still declare this in its constructor). For this to be truly useful, we have to be able to wire up the Content.Service container at runtime from either a configuration file (the default behaviour) or from code (during testing).
Sidebar: On DI Containers
To digress briefly, you will notice that the Current.Service container is a custom-built one, rather than a Unity or other DI framework’s container. The reason for this is twofold:
We want to minimise our product’s dependencies on other products or open-source projects.
We want developers using our product to be able to know in their IDE whether a given service can expect to be found wired up in the container, hence our use of methods like ContentServiceGet() and SecurityServiceGet().
That second reason is very important given that we are still actively developing the Elcom.API and pushing it out across all of our product’s many modules. One version of CommunityManager.NET may have very different abilities to the next one, and our partners’ developers may be dealing in multiple versions at once – hence the need for good IDE support.
Saved by the Static Property
So we like the syntax afforded us by static/shared methods, but they present problems when it comes to setting the values during testing. We looked at lots of options, including using delegates or even events, but they all made production code smelly in order to aid testing, and that didn’t sit well with us.
What we ended up doing was creating an IServiceContainer interface which declared all the types of services that could be returned, and using a factory within the Current.Service method to build a DefaultServiceContainer from a configuration file. We then provided a Current.ServiceContainer object which would contain the concrete version of IServiceContainer being used and which could be overwritten when testing.
''' <summary>
''' This holds the concrete implementation of IServiceContainer that is used. This is writable in order to help testability.
''' </summary>
''' <value>The concrete implementation of IServiceContainer that is used by Current.Service (or that is created by that function).</value>
Public Shared Property ServiceContainer As IServiceContainer = Nothing
Public Shared Function Service() As IServiceContainer
Dim currentContainer As IServiceContainer
If ServiceContainer IsNot Nothing Then
' retrieving the previously created one (or the testing one if its been written by our tests)
currentContainer = ServiceContainer
Else
Dim factory As New ContainerFactory
currentContainer = factory.ServiceContainer
' obviously we need to store/cache this and not just instantiate each time, so put it back into Current.ServiceContainer
ServiceContainer = currentContainer
End If
Return currentContainer
End Function
This approach works really well, provided you don’t mix production and testing code in the same application instance, which we never do. It doesn’t offer a generic container for developers to use for custom projects built on CommunityManager.NET – but there is nothing stopping them using Unity or other generic containers for their own purposes.
In case you’re wondering this has become a pattern we’re using across the Current object’s static/shared methods, including of course Current.HttpContext. Our caching at the moment is still fairly primitive (stick the object in the static property), but we are looking at making improvements in that area in this release too. If nothing else we have a proxy for Session objects that can be swapped at test time for something not dependent on web projects (although ASP.NET cache is available outside web projects anyway, See Scott Hanselman’s reference to using HttpRuntime.Cache outside ASP.NET).
I just removed my Blogrolling links as Google warns me that the site was being used to distribute malware. It's a real shame, but it opens up the door to me looking at freshening the design for the first time in a few years.
Continuing from my previous post, this one is more in line with the actual talk I gave on the 13th April at The Internet Show in Melbourne. We will be putting the actual transcript and slides of that talk (and video if the quality is good enough) up for people to download in the next week or so.
If you are interested in Web 2.0 and social software then you should have a look at Enterprise 2.0, which could be thought of as just Web 2.0 within the enterprise, although the originator of the idea, Andrew McAfee has a more precise definition for it:
“Enterprise 2.0 is the use of emergent social software platforms within companies, or between companies and their partners or customers.”
He places particular emphasis on the idea that it should be emergent, and for this reason excludes traditional intranets as part of the Enterprise 2.0 toolset.
“Emergent means that the software is freeform, and that it contains mechanisms to let the patterns and structure inherent in people’s interactions become visible over time.”
The whole idea of emergence is a tricky one, but a good example is the way Google assesses the relative merit of web pages based on the number (and quality) of inbound links, something which emerges over time as people find a page useful and link to it, rather than something pre-planned and orchestrated. A more concrete example is the idea of not placing paths in a garden up front, but allowing people’s actual movement to determine where paths should be placed – hence having them emerge as real patterns of use are known.
A point worth noting is that this means that the early structure or format of an Enterprise 2.0 tool can be expected to change over time. Initially it may seem somewhat useless, and not the sort of quality resource the business hopes it will be. This is a good thing as this quote from Art & Fear illustrates:
“The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the ‘quantity’ group: fifty pound of pots rated an ‘A’, forty pounds a ‘B’, and so on. Those being graded on ‘quality’, however, needed to produce only one pot -albeit a perfect one - to get an "A". Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the ‘quantity’ group was busily churning out piles of work - and learning from their mistakes – the ‘quality’ group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.”
The point about emergence is that it usually leads to a more appropriate and higher quality result than something meticulously planned from “theorizing about perfection”.
It is important to realise that the interactions that will take place, and help the emergence of patterns and structure, will be around ideas and especially the communication of ideas. Any Enterprise 2.0 initiative must have as its basis the ability for people to express, challenge, endorse and modify their and other’s ideas.
It can seem that some of this is a waste of people’s time, creating yet more ideas (some rubbish) for them to have to trawl through and interact with. We should remember that what ultimately matters is how it helps to optimise overall organisational effectiveness, not necessarily the impact on individual efficiency. Efficiency is one of the items that gets addressed as complexity emerges in the unstructured content that Enterprise 2.0 deals with – good tools will help you deal with this complexity.
What Can Enterprise 2.0 Do?
One of the biggest differences in Enterprise 2.0 tools is that they bring broadcasting to the average employee. This means that everyone can take advantage of the virtues of pull versus push publishing. Instead of identifying who should see something, and then pushing it into their email inboxes, or onto their IM clients, pull publishing allows the idea to be pulled into someone’s attention when they want it to be. Key enablers for pull publishing are RSS feeds and feed-readers, easily browsable content and micro-blogging enterprise tools like Yammer.
Another key difference is that most Enterprise 2.0 tools have come out of the consumer marketplace. That means they are highly usable and are designed from the ground up to be easy to learn. It turns out that’s a really important point, because it makes adoption across an enterprise much easier than most enterprise software. One key point is that the tools should address security and legal concerns, unlike most Web 2.0 tools, the content being dealt with is commercially sensitive.
Here are some business problems that Enterprise 2.0 helps address better than many other tools:
Bring new employees up to speed Wikis allow corporate knowledge to be easily captured, reviewed, edited and re-published as necessary so that new employees can quickly see the latest information. Internal blogs can operate the same way, but have the additional bonus of making it obvious who knows what, which gives the new employee someone to connect with.
Accurately forecast something Some cutting edge applications of Enterprise 2.0 include crowd sourcing from within the organisation, using internal prediction markets to identify probable issues or forecasting delivery dates or prices.
Help customers One of the oldest Enterprise 2.0 ideas, and something pre-dating Web 2.0, self-help community forums enable customers to be helped by other customers acting as a volunteer helpdesk.
Make things findable Blogs (and intranets) that implement folksonomy tagging well allow users to easily tag things to find later and make content more browsable. Good enterprise search solutions that cover blogs, wikis, intranets and other Enterprise 2.0 tools also help make things more findable.
Broadcast ideas (pull not push) As mentioned above, RSS and Yammer allow users to publish content in a way that broadcasts it outside their normal circle of influence, without creating disruptive interruptions as push publishing tends to.
Transparent project progress Using a wiki, blog or a simple project management tool like Basecamp to track project progress both allows the emergence of patterns and can make those visible to people outside the immediate project team.
Communicate to the rest of the organisation Department blogs can act as venues for communications between components of an organisation, and capture the discussions around those communications for future users to review and understand.
Helping upcoming leaders network It is well established that upcoming leaders do better when their networks are more diverse and cross organisational boundaries. Internal blogs, the comments around them and a good flexible corporate directory tool can help upcoming leaders get noticed outside their existing teams and make the connections they will require to succeed.
Enhance employee self-learning I’ve mentioned before David Maister’s opinion that most training is useless and the current focus of much etraining is actually on how to teach the individual to become a better learner, rather than pushing particular content at them. Wikis, blogs and social bookmarking all place a part in enabling better self-learning.
Improve innovation Innovation is done by creative people, usually passionate creative people (see my previous post on passion) and Enterprise 2.0 helps them do this by making it easy for their ideas to be shared with internal audiences to inspire and call forth more ideas from them. Any Enterprise 2.0 tool can help innovation, but the best ones are often internal blogs.
Below is a great slidedeck that illustrates how someone might use these tools:
What should you look for in an Enterprise 2.0 tool?
You want to start with one that is more of a toolbox than a single tool, a good start is to look for something that offers blogs, wikis and a well-integrated corporate directory. You want something that is expandable, so you have the option to add more tools later.
Any tool you choose should play nice with other enterprise software, so you should find something that offers single sign-on (SSO) with your particular network, for example Active Directory/LDAP integration and that satisfies your IT department’s security needs.
Playing nicely with other Enterprise 2.0 tools is also mandatory. In this case that is mainly done by providing (and consuming) RSS feeds and integrating with your chosen enterprise search tool, but integration with a corporate directory offering will become necessary.
Basic functionality to allow emergent behaviours is also necessary, at a minimum this requires tagging and the ability to comment on anything, but micro-blogging and social bookmarking are also good candidates for this.
If you want to try something without involving IT, then you can look at various hosted solutions (such as Yammer), but eventually you should make sure that IT is happy with your choice of tools – especially of it ends up being something that you need to host yourselves, or if it will contain content vital to the continuity of the organisation in the case of a disaster.
Do I Need It?
Small companies, or larger ones faced with large amount of routines tasks and few opportunities for passionate creative work, might find that Enterprise 2.0 offers less robust ROI than most IT purchases, but even they may benefit from using Yammer or similar low-cost, hosted tools.
Companies in highly competitive environments, where the ability to be agile and quick to react to change is important, or organisations seeking to ignite the passion of their employees and find more effective ways to work will find that these tools are indispensable in helping flatten the organisation and efficiently distribute ideas.
I’m in the midst of preparing for The Internet Show in Melbourne, 13-14 April 2010. As a sponsor my employer, Elcom Technology, has several slots for presentations. We’re doing a case study on a social networking startup and a CMS clinic, but most importantly for me I am also doing a session on Web 2.0 and Social Media within the enterprise. These are the key ideas behind that talk, although this is more detailed than I will be on the day.
Passion is one of those wonderful ideas, it is hard to quantify or measure, but unmistakable when you meet it. In the business world we tend to think of it as messy, disorganised, hard to manage, hard to inspire and hard to control.
However, passion is one of the greatest competitive advantages, with something they are passionate about, people will spend more time, think more creatively and fight harder than they will with other things in their lives. It is also well-recognised that passionate employees create passionate customers, and that’s something any business should be interested in.
Deloitte’s 2009 Shift Index says that “Passion is when people discover the work that they love and when their job becomes more than a mode of income.” They describe the need for passion in terms of competing for employees:
“Why does passion matter? Because staying competitive in the newly globalized labor market requires all of us to constantly renew and update our professional skills and capabilities. The effort required to increase our rate of professional development is difficult to muster unless we are passionately engaged with our professional activities.”
A History Lesson
Around 100 years ago the Ford Motor Company implemented an assembly line in order to boost the production of the Model T. Initially, Ford raised the wages of assembly line workers to keep them interested in the innovations they were rolling out, but now we think of assembly lines as places where cost is minimised by reducing the complexity of the work across many simple steps, and therefore minimising the training (and wages) required for employees.
By simultaneously innovating to a lower price point and creating a middle class that could afford their product, Ford managed to reach a dominant early lead in the production of motor cars. This precipitated a movement from craft production to mass production and in large part was based on scientific management, a term coined by Frederick Taylor.
The motor car industry might have continued in this vein forever, except for the advent of the Toyota Production System (TPS). The founders of Toyota were unimpressed with Ford’s assembly line, but found a way to improve it greatly. Their ideas were wildly successful and a host of studies tried to understand the core ideas in the TPS in order to apply it in the western world. Thus we received just-in-time manufacturing, total quality management, continuous improvement and lean manufacturing.
Most of these ideas have failed to find as fertile soil in the west as they did in Japan – however the evidence is that the difference is not cultural (Toyota runs plants in America run as well as they do in Japan), predicated upon Japanese corporate solidarity, or based on some secret sauce hidden from researchers. In fact the key items were in plain view all the time, but hidden by the biases the researchers brought with them.
There are two key differences they ignored:
1. People Management
The first key difference was the way people were treated. In the TPS people at all levels are valued and given control of their area of work. For example, an assembly line worker is able to shut down the entire line if they find a defect, and will then be part of the team tasked with finding the root cause of that defect and solving it.
2. Practice Makes Perfect
Another key difference is that the Japanese understood W. Edward Deming’s statistical process control methodology, and saw their assembly lines as being imperfect and in need of continuous improvement, rather than the perfectly defined processes that scientific management assumed.
An illustration of this is the pottery class that was split 50/50 between students who were told they would be judged on the quality of a single pot at the end of the course, and ones that were told they would be judged on the quantity of the pots they produced. The ones who focussed on quantity ended up producing better quality pots because they learnt from each one they created, whilst the others got stuck in trying to create the single perfect pot first time.
Eventually in the mid-80’s, Ford asked Deming to help them turn around their quality problems. They were surprised when his focus was on their management methods, but his influence was quickly seen in the profitable Taurus-Sable line.
Today these principles are working their way into other areas of work, through Agile software development and the general concept of Lean. An important key concept is the idea of waste – whether it be spare inventory, transportation, defects, unnecessary motion, over-production or over-processing. The well-known Scrum methodology lists three important pillars for empirical process control:
Transparency Know what is happening and be able to measure everything.
Inspection Regular and frequent inspection of the process to ensure it is functioning without waste.
Adaptation Adapting the process to remove any waste.
So What?
A big part of Deming’s management principles was helping people re-discover “pride of workmanship” (or passion!) in their work, and removing barriers to them doing this (e.g. work standards, quotas, annual ratings, management by objective, etc.), substituting leadership for those barriers.
Whilst Deming’s methods have transformed the manufacturing industry, with companies like Dell and Boeing taking lessons from the TPS and applying them well, there are many industries where Taylor’s scientific management methods still rule, mostly because of habit and management (mis)training.
I know that I learnt how to manage very much in line with scientific management techniques (mainly by osmosis from poor managers). Plan, control, punish, reward, etc. The reality is that there is a shift in our working lives, we need more passionate creatives than ever, more artisans or craftspeople than unthinking drones. There is scarcely any industry or business that does not need at least some of their people to be passionately involved, engaged and thinking outside the box.
That last point is key to applying this. For some organisations the amount of passionate creative work that overlaps their routine work is minimal, for others there is almost a total overlap. The trend is towards more passionate creative work, and we will see that increasingly the leaders in their field are organisations that tap into this and harness it properly. Ford’s initial success in keeping their assembly workers by doubling their pay was short-term, soon the rest of the employment market matched their wages and the middle class expanded rapidly thereafter.
Your efforts need to match the amount of passionate creative work that overlaps routine work in your industry – but don’t shy away from finding ways to move away from the industry average and get more creative work in there.
How Can We Do It?
The question is how do we help people tap their passionate creativity in the workplace so they want to stay?
We need to go back to the basics of good management again to find out what really motivates employees. Daniel Pink talked about this at TED in August last year.
“There is a mismatch between what science knows and what business does. And here is what science knows. One: Those 20th century rewards,those motivators we think are a natural part of business, do work, but only in a surprisingly narrow band of circumstances. Two: Those if-then rewards often destroy creativity. Three: The secret to high performance isn't rewards and punishments, but that unseen intrinsic drive. The drive to do things for their own sake. The drive to do things because they matter.”
In summary Daniel points to three key ideas for managing people in the 21st century:
Autonomy The urge to direct our work and have some say in what we do.
Mastery The desire to get better and better at something, to make progress and overcome challenges.
Purpose The yearning we have to work in the service of something greater than ourselves.
There was some interesting research reported in the Jan-Feb 2010 Harvard Business Review that supports the power of mastery in motivating employees:
“On days when workers have the sense they’re making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak. On days when they feel they are spinning their wheels or encountering roadblocks to meaningful accomplishment, their moods and motivation are lowest.”
Deloitte’s 2009 Shift Index had similar findings about autonomy and mastery:
“24 percent responded that flexibility, freedom, and autonomy were the reasons they “loved their job.” Similarly, 23 percent of the respondents cited challenges and opportunities for problem solving and creativity as the reasons they loved their job.”
These keys can all be found within the TPS, and are the foundation of any great 21st century business. If they can work for assembly line workers in one of the world’s largest car manufacturers, then surely they can work in our office environments?
More to the point, if we don’t offer work environments that have these keys, then we can expect to see more of our best and brightest leaving to go freelance, or joining that new startup, or even finding a big company that gets this idea.
Getting a Leg Up from Enterprise 2.0
I’m a Technical Director, so of course at some point I want to see just how technology can help us, and in this area as so many others there are some interesting possibilities thanks to Enterprise 2.0.
Learning
Modern creative work places a huge demand on people to be constantly learning, diversifying their experience and increasing their speed of uptake of new ideas and skills. More then ever before success demands that people self-educate themselves, and with information overload and the skyrocketing complexity of our global business environment (where your competitors may just as easily be half a world away as down the road) that is harder than ever.
Enterprise 2.0 offers lots of help in the area of learning and knowledge transfer.
Wikis These are great for helping people record their knowledge, and then allowing that knowledge to be reviewed, improved, updated and generally kept alive.
Blogs Fantastic for putting ideas out there and getting feedback on them. They can provide employees with acceptable avenues for bridging great gaps in relative seniority (e.g. letting a new hire question the corporate vision statement) as they can allow people other than the original author to respond and correct mistaken ideas. The ability to browse posts by chronology and/or tags means that content is more usefully categorised than it would be in an email inbox.
Social Bookmarking Whilst bookmarks can be overrated, if properly categorised and rated, they allow people to make new information available to their colleagues and can act as scent as to who is most interested or interesting.
Enterprise search Having an effective and useful enterprise search tool is a must-have Enterprise 2.0 tool. Most Enterprise 2.0 content is unstructured and a good search tool is essential to ensuring that people find the right content when they need it.
Networking
There is a need for us to connect with ever greater numbers of people, and being increasingly time-poor to find the right people to connect with. Research has shown that high performing individuals maintain better networks than others, and in particular that their networks are more diverse/disconnected. This allows them to “see the big picture better, generate innovative solutions by integrating the expertise of those with unique backgrounds, position their efforts well, bypass bureaucratic gridlock and obtain necessary resources and support.”
Enterprise 2.0 makes it possible to find the right people in your network by reviewing their ideas and following the commentary and discussion about those ideas. It also helps people develop connections beyond their immediate team or management hierarchy.
Corporate directory Having an active and useful corporate directory, one that tracks projects worked on, positions held and teams an individual has belonged to can help identify key people.
Employee pages Giving employees their own page to talk about themselves can be risky, but for those passionate creatives it can offer a way to get their ideas out there, attracting others that have similar interests and passions.
Blogs The commentary and discussion facilitated by blogs, along with their attachment to individuals (and hopefully the corporate directory), makes them an ideal place to connect with others and find out who else you should connect to.
Yammer Internal tweeting tools like Yammer offer interesting possibilities as people can follow who they like within the organisation and find out who is following them.
Managing Autonomy
One of the main reasons people fear worker autonomy is that they will lose oversight of what is going on. Obviously implementing transparency properly means this is not an issue, but there are problems with managing transparency when collaboration is limited to email inboxes and offline meetings.
Enterprise 2.0 offers ways for collaborative work to be both done at a distance (of either time or place), and to be recorded in ways that allow for relatively easy monitoring by managers who want to help ensure that responsibility is taken seriously and known problems are not repeated.
Wikis Tracking progress on a wiki gives managers insight into what is happening and an avenue for querying ideas and outcomes.
Online document collaboration Collaborating on a document online makes the draft version available to people beyond the immediate team, often in a read-only version.
Basecamp online project management tools like Basecamp are highly regarded for their ease of use, simplicity and ability to facilitate complex project discussions and task workflow.
Google Wave Still in Beta, and with real performance and usability problems still, Google Wave offers interesting possibilities with low-overhead asynchronous conversations organically evolving into rich document collaboration opportunities and even real-time conversation.
Making Progress
We have seen that a key motivator is the sense of making progress, achieving real results and conquering challenges. One way our current systems can rob us of this is by interrupting our state of flow and causing us to drop out to check something that turns out to be unnecessary – it is estimated that a 1 minute interruption kills 15 minutes of productive time. Two deadly forms of this are unimportant emails and face to face social desk visits.
Enterprise 2.0 tools can help reduce the amount of email flow by moving items to more useful forms of communication that rely on a pull method of distribution (where users choose to use it), rather than the invasive push method employed by email.
RSS feeds By eliminating the push nature of methods like email, RSS feeds give a generic method for tools like blogs and wikis to make their data available for the user when they want it.
Yammer By bringing micro-blogging to the enterprise tools like Yammer remove the instant interruption hassle of instant messaging (IM) and provide an outlet for broadcasts of ideas that may be useful, but don’t need to be considered immediately.
Enterprise 2.0 tools can help move social interaction away from invasive face to face time in the office to more asynchronous means, or at least ones that include less wasteful interruption time.
Yammer Social engagement via micro-blogs like Yammer is ideal because it is asynchronous, based on the push/broadcast mode of communication and carries an implicit understanding that it is not important content.
Intranets/Wikis Placing social event information online, and providing interactive photo galleries can help reduce the amount of social interaction that must occur face to face.
In Summary
Deciding to manage work empirically, through transparency, inspection and adaptation can help give your employees the sense of autonomy, mastery and purpose that is necessary to untap their passionate creativity.
There are key ideas I have not covered here, such as the willingness to accept failure as learning experiences, the need to align authority with responsibility, and responsibility with ability that must be addressed for this to work well.
However untapping passion is not only possible, but well within our reach. It fundamentally depends on the willingness of senior management to set the direction, free their people and unleash their own passion.
Finally, Enterprise 2.0 offers some interesting tools to help manage and enable this change in our organisations. But as ever, technology plays an enabling and supporting role rather than being the driver of true change.
Thanks
There is a lot packed into this particular post, but a few people were key in helping me understand these issues.
Jason Yip, from ThoughtWorks Australia, whose passion for Lean got me interested in looking at Agile software development and whose ideas and blog have helped me work out my own thinking.
Lachlan Heasman, also from ThoughtWorks Australia, who runs the Sydney Scrum Meetup, and is a good friend and great Scrum trainer.
Craig Bailey, who in a year as my boss ignited hope in me for great managers once again, and who has gone on to embody following your passionate creativity wherever it may lead.
Chris Scoggins, my first great manager and a great example to me of how to mentor and build leadership into your staff.
Daniel Pink for bringing the hidden truths about motivation into plain view, and pointing out the Emperor’s New Clothes of management.
My Dad, for always making me question what is true, and helping me understand my own passionate creativity.
You're developing a great web application, training course or social software strategy. You cost it and it looks like a substantial piece of work, so you need to get executive approval. Putting together a list of the benefits you find to your dismay that the list is full of terms like "easier", "more efficient", "more usable" and "collaborative". You know your executive will ask questions this list doesn't answer, "How will you know you're successful?" and "What's it worth to us?".
There are two common (and wrong) approaches to this question:
It's Web 2.0/training/social, it's intangible and can't be measured.
It should add to the bottom line, so just measure revenue changes.
The first one incorrectly assumes that intangibles can't be assessed, but market analysts know that they certainly can, and indeed regularly are, just ask what Google's stock valuation is based on.
The second one jumps to the über-goal and ignores the fact that as everything the organisation does can potentially affect revenue, it will be nigh impossible to really know whether any change in the bottom-line is the result of this particular web application, training or social software strategy (you can easily have a great success in one area cancelled out by a horrible mess in another).
Fortunately this problem is well known. Unfortunately the answer is hard. That is, hard as in deciding what you want for your birthday, not hard as in needing a PhD in Applied Rocket Science.
Find your desired user behaviours
The bottom line is that you need to find what change in user/trainee behaviours will support your business goals and then use that to derive metrics that can be measured (and eventually valued).
David Maister talked about the importance of identifying desired behaviours in his article Why (Most) Training Is Useless.
There is no point putting on skills training if there is no incentive for the behavior; the people don’t believe in it and they don’t yet know exactly what it is they are supposed to be good at! ...
What behaviors by top management need to change to convince people that the new behaviors are really required, not just encouraged? If the behavior is going to be optional, then so should the training be.
In other words, if we don't know what behaviours we want training to encourage, or if we don't actually support the display of those behaviours (e.g. through measurement and feedback) then we can't expect our training to actually help our business goals.
In exactly the same way software applications (not just web or social ones!) are often built without thinking what change in user behaviours is really desired or how the change in user behaviours will be measured - thus guaranteeing that even if success is achieved there is no way of valuing it.
ROI for difficult stuff
Adaptive Path introduced a way of valuing user experience by reflecting on the change in behaviours we desire to solve our business problem. They gave us the graphic below as a way of envisaging how business problems map to user behaviours and how they in turn can be mapped to valuable financial metrics.
Business Problem = a specific problem you want to affect
User Behaviour = a change in user behaviour that would introduce the effect desired
Behaviour Metric = a way you can measure the change in user behaviour
Value Metric = the dollar value we can apply to the behaviour metric
Financial Metric = the expected amount of user behaviour change to come from the project, multiplied by the value metric and compared to the expected cost of the project
A specific example might help make this clearer. Imagine you want to increase leads and you decide to do this by improving your website's ability to elicit customer responses via the contact us form:
If we add some case studies to the website, and then place the contact us form at the bottom of each one as a call to action then we might expect some increase (assuming this was a new initiative for our website).
The behaviour metric for this is the number of leads received from the website contact form per month. Our sales team has estimated that 1 in 10 leads becomes a sale, worth on average $1,000 to us (whether revenue or profit depends on what you are most interested in - the smart money is on profit though).
Based on our website's traffic patterns we expect to increase our leads from 7 per month to 20 per month by implementing this measure. If we are happy to get a breakeven return on investment (ROI) over the next 3 months then we could invest $1,000 * (20 - 7) * 3 = $39,000 in the project.
Before someone tries to tell me I don't know how to value project returns, I know that you could use Net Present Value (NPV), Internal Rate of Return (IRR) or other methods to ensure this is comparing apples with apples across projects, time and investment opportunities - but that's not the point of this post.
Now we might well spend a fraction of that on case studies and a contact form, but if we wanted we could now justify getting a professional copywriter to help shape up our case studies and spend a bit on usability testing to ensure our contact forms get out of the way and give us the leads as easily as possible.
Okay, okay, this is a fairly simple example, with straightforward metrics. After all, we might well not know how much a lead is worth, and often we're asked to solve business problems far more complex than this one.
What if I’ve got no history (i.e. I’m a startup)?
We have used this process with startups to help them prioritise wildly diverse feature lists when they do not have the budget to afford to build it all in their launch timeframe.
(Aside: There is a lesson here about launching a simple, compelling product and then iteratively adding value to it based on user feedback, the problem is that in many startup ideas there is usually no simple, compelling offering. It's the fault of funding requirements, but more about that in another post.)
Startups do not have financial history to fall back on, and even with good financial modelling they might only have a guess to give you for their value metric. In this case we take the prioritisation this gives us and keep the rest of the information for analysis of the success of the startup down the track and (as importantly) for helping us identify which changes we should look at implementing later.
What if you don’t know what to change?
The methodology is still useful even when you have a complex situation with incomplete information. If nothing else it focuses your attention where it belongs, on the problem you are solving and the user/trainee behaviours that you think will help solve it rather than on the application technology or the subject matter of your training courses.
Of course you often don’t know what to do to create a particular desired behaviour. In this case a bit of prototyping and A/B testing can go a long way. Google Website Optimizer does a great job of helping you do this with content or separate functional pages, but it does require two separate pages exist, and sometimes you just want to tweak the way a particular feature works (e.g. adding a couple of extra fields to a form).
Assaf Arkin has created a plugin for Rails called Vanity that supports A/B testing in a rather unique way, by creating an easy way for developers to embed the tests into their code and then run them for a set number of iterations and/or exceed a set probability for one option over the other.
By using a simple API, and elegant admin functionality, Vanity provides a very viable way of testing one idea against another. While the time to make such a change is greater than not doing the A/B test – the marginal extra cost is small enough that you do it in order to find out which option really works better.
Assaf has a great post explaining how this is really Experimental Driven Development in action. He explains the cost/benefit tradeoff this way in the comments section:
“You start with an idea for a change that will improve your software. Your baseline cost of development is having both alternatives — before and after the change. Without EDD these alternatives will be separate in time, with EDD you’re going to have some overlap (the duration of the experiment).
For the experiment, you only need a skeletal implementation, you’re not committed to fully developing the feature until after it proves itself. For small changes it makes little difference, the cost is the same.
For complex changes, you can save a lot by not fully developing features that don’t matter. You’re going to know whether a feature matters or not quickly enough, and with data to back up, that you can make the decision to *not* develop it further.
You can also kill unused features early. So these are two ways to reduce development costs using EDD.”
Summary
Get behind whatever you are doing and try to understand the underlying business goals, the user behaviours that would support those and derive the ROI from that. If you are not sure what would best support the change in user behaviours, then try A/B testing to establish which way you should jump. Whatever you do, don’t allow yourself to be sucked into doing something just because your competitors did, or to be “simpler”, or more “usable” in some undefined, unaccountable, way.
Agile specifications, poor user stories – 4 (good enabling specifications might be 3-5 pages long – before sprint planning)
(for venture companies Jeff finds that 2 sprints planned is necessary)
Product owner, product owner with backlog – 5 (or 2 with last project!)
Product backlog, single product backlog - 3
Estimates, backlog estimated by BA – 0
(Jeff said that usually as teams get better their stories get smaller and eventually are about the size of tasks, and then estimating changes to use points vs hours – surprising what can be untangled and done separately)
Sprint burndown chart, no chart, but team knows velocity – 0 + 3 + 2
(Jeff mentioned that partial completion of tasks creates a high-risk environment)
Team disruption, project leaders telling people what to do – 3
(self-organise to maximise velocity)
Team, no emergent leadership - 1
Total = 4.33
Most of the room were between 2 and 5, and apparently, most of OpenView’s venture companies start out around 4, but when they work on it they end up around 6. It looks like TIDC might have a great Scrum team as someone from there scored 8 for their team! (they were the only one higher than 5)
If your reference stories change then so do the story points. But Jeff said it is really the delta in velocity that is interesting. One of the symptoms of hyper-productive teams is that you get asked to slow down!
Sustainable pace
Quality
Velocity
“Balanced Scorecard” (not right term, but Jeff couldn’t remember what it was)
Jens recommends the XP game for teams to learn about velocity.
How long does it take to fix a bug from CI/automated testing. If longer than 2 hours then create an impediment list and get the Scrum master to remove them. Simple metric, track the day you start a story and the day you finish a story and then compare to your standard process efficiency (usually around 20% – measures the quality of your backlog) {calc elapsed days versus theoretical ideal days based on velocity}. Raising the efficiency meant getting the backlog well enough detailed that you spend less time waiting to do a particular item. Measuring the time to Done.
Speed of testing is usually the bottleneck, and is more important than the speed of coding. So interrupt devs immediately with a bug, rather than leaving them to finish what they’re doing. The availability of testable code is another way of thinking of it.
Just evaluate the code in production is one way of incentivising people.
I asked about how to handle client projects using Scrum, Jeff mentioned that Systematic is doing big fixed price contracts using Scrum. They provide 2 bids on every project, with the Scrum bid at around half the price.
In response to someone’s question about Scrum, Jeff mentioned he’d written about the answer in an article titled Future of Scrum from the Agile 2005 conference.
Metrics to Live By
Jeff got me hooked on metrics as it is obvious when talking to him that empirical process control requires metrics to be successful. Some of these metrics assume that you use story points for estimating, which we have done with some success on one project. To do this well you need a range of reference stories of various sizes and rough sizing (e.g. Fibonacci numbers) that the team can agree on the size of.
Here are some of the metrics Jeff mentioned:
Backlog Velocity = story points/sprint
Sprint Velocity = story points ‘done’/day
Efficiency = story’s ideal days/actual elapsed days from ‘start’ to ‘done’ (if an item should have taken 2 ideal days, but it actually took 10 days from the ‘start’ to the ‘done’ date, then you have 20% efficiency)
Churn = % of ‘done’ items that testers send back to developers for fixing (if all items churns once then you have 100% churn, if half of those churn again then you have 150% churn! Ignore size of item when calculating)
Jeff has an upcoming conference session on this very topic and he discusses it further in his Excel Spreadsheet for Hyperproductive Scrum Teams post. The spreadsheet seems a little hard to get into, but I’ve given it to our Solutions team to review.
How do you create a worthwhile specification of the requirements for a system?
As an Agile Scrum practitioner I’m supposed to answer this by pointing to user stories, but as others have found before me, these are a slippery beastie to define. Cat Schwamm takes a stab at a definition, but finds Scott Bellware telling her she is following Scrum too blindly and should go change what she’s doing.
Scott’s point of view is interesting, but like a lot of his comments he is coming at the problem from the frame of his lean methodology, which is not fully explained and therefore extremely hard to argue with/understand. This is not Scott’s fault, he is after all busy consulting not writing Agile methodologies, but it does make his commentary a tad alarming when one first reads it.
The classic format of a user story is:
As a [user] I need/want [feature] so that [benefit].
Or as Cat puts it:
As a [role] I need [feature] so that [business value].
Cat points out that this is fairly barebones, and leaves lots of scope for you to choose the wrong level of granularity for your user story. She points out that her team also follows the INVEST acronym and use the concept of minimum marketable feature (MMF) as defined by James Shore.
MMF = “Smallest possible set of functionality that, by itself, has value in the marketplace”
This is obviously working for her team, but I suspect they benefit from having a single Business Analyst who works everything through for them and ensures some consistency across user stories. This is actually very Agile, as the manifesto points out we value “individuals and interactions over processes and tools”. However, we still need some processes/tools for those individuals.
Scott Bellware’s suggestion was to change the format to:
As a [role] I want to [goal] so that [motivation].
He wants us to avoid mentioning the software altogether and have the user story simply capture what the users actually do (or will do once they have a system to help them). He then divorces the user story from work items altogether, and simply relegates them to the role of being information about the goals of the system. This may work for him, but it then begs the question of how he defines what the work item is all about, which is where we started talking about the need for user stories …
I have been reading a great book called Designing for Interaction by Dan Saffer that gave me another viewpoint on this issue. One of the things I learnt from this book was that user-centred design (UCD) is not the best way to design interactions, it is simply one of the possible ways you could design them and its relevance depends upon the goals of the thing you are designing.
Dan Saffer lists 4 different approaches to interaction design:
Cat’s user stories actually sounded like activity-centred design, and Scott sounds like he is more interested in user-centred design. Quite possibly they are both right in the contexts they are working in. Neither one may be better than the other (Scott at this point would probably call BS on me, he has previously talked about the need for user stories to communicate expectation).
Coming back to my own issues with user stories, I need to ask what sort of design approach am I taking, otherwise I will find my user stories being all over the place. Is the user story meant to encapsulate the MMF in a single story, or is it supposed to be used to specify all ways of looking at the functionality.
As an example, when looking at the search function for administrators of an organisation I have specified:
As an admin I want to be able to search for a member by their Member Id so that I can find a specific member quickly.
As an admin I want to be able to search for one or more members by their Member Type so that I can target an action against all members of a specific type.
As an admin I want to be able to search for one or more members by a wildcard search of first and last names so that I can find a member just by knowing their name.
As an admin I want to be able to search for one or more members by region or industry so that I can find members from specific industries or regions.
As an admin I want to be able to search for one or more members by a wildcard search of job title so that I can find members with specific job titles.
As an admin I want to be able to search for one or more members by member status for my organisation so that I can target an action against all members of a specific member status.
As an admin I want to be able to search for one or more members by activation status so that I can target an action against all members of a specific activation status.
As an admin I want to be able to conduct a search against multiple facets of a member at once (e.g. by member status, industry, member type and job title) so that I can get very specific search results.
As the system I want to give admins a common page which allows them to search for members for all sorts of reasons and then target actions against the members found.
As the system I want to ensure that admins can only ever see their organisation’s own members in search results.
You can see the format slipping towards the end of that list, with the “so that [benefit]” element disappearing. There is also no regard to the INVEST principles, particularly the independent one. If I adopted another (MMF?) approach I might reduce all of that to:
As an admin I need to be able to find the members I’m interested in from my organisation so that I can work with those members’ details.
Scott’s format might leave me with:
As an admin I want to work with my members so that I can help them use our organisation’s online tools.
I think this demonstrates that there is a lot of variance possible within this simple definition of user story. In the past I think I have over-specified functionality with user stories, leaving my developers with a weird tension between overly specific (and hence out of date) user stories and little or no supporting documentation around other design issues.
This actually speaks to the N in INVEST, as Cat explains it:
“Negotiable: User stories are not a contract; they are reminders for the team to discuss and collaborate to clarify the details near time of development
What a user story really is is a placeholder for a conversation. We’ve gotten away from writing strict, rigid use cases and into these user stories, which are much better for the way the business world really works. By writing a user story this way, I am opening up a higher bandwidth conversation. Instead of a developer just reading what I have and doing it word for word, now we can talk about things and make sure everyone is on the same page and fully understands the business value and the needs of the user. I like that Kelly specified “near time of development” though; that’s one thing you’ll always find: CHANGE IS A CONSTANT. Friggin annoying, but it is inevitable. The closer to development time you talk about something the more likely it is that you’ll have the best information and the most clarity on the item.”
I especially like the idea of a user story as a placeholder for a conversation. Of course this depends on your developers actually being willing to talk to anyone about the requirements (sometimes they still seem to think that it is faster to code away on assumptions and correct later than to have a 30 min conversation up front and ensure you know what you are doing!).
“Here’s the thing, stories and tasks are only part of the equation. Stories alone aren’t enough to define a system, and trying to define everything in text is a fool’s task. (I’ve been that fool). You need a full arsenal of specification tools to do the best job possible.”
I think I’ve been the fool Scott mentioned myself (once or twice). Scott (and Cat) mentions 3 other tools that they use as well as user stories:
Mockups Basically a low-fidelity prototype. They are great for eliciting feedback about visual design and interaction issues without leaving anyone feeling like these ideas are final. They are poor for actually designing off of as they frequently ignore or skimp on the design of areas that were not pertinent to the original design issues being explored in them.
High Fidelity Design High-fidelity screenshots showing exactly how the screen should look. These are great when you need signoff on something from outside the development team as they show everything that needs to be taken into account. They are poor when the design needs to change and you don’t have time to re-do those rich initial screenshots for the change request. Actually they are poor for Agile, full-stop, as they reek of BUFD.
Conversation and Whiteboarding This is the higher bandwidth conversation that Cat referred to. This is a chance to meet, collaboratively engage each other and work out what the business need for this feature is. The caveat is that it is only as good as the conversation and whiteboarding ability of your developers, and it requires that the customer be available immediately when the developers need them (this is why Agile doesn’t work for many projects).
There are other good ideas for artifacts to capture interaction design ideas, such as:
Acceptance Tests Here I mean a light version of the full test scripts that are possible. Ones that match user stories come in the form: Given that [context], when [event/action], then [expected outcome]. Like user stories they have the same problems with being at the right scale.
Key Scenarios Penny Hagen describes these as combinations of user stories that help define the strategic direction of the website. Whilst she uses them as a tool to help define design strategy early on, they have a useful purpose in helping developers understand the context of the user stories they are working on.
User Pathways Again Penny Hagen describes these as a detailed view of the pathway a user needs to follow for a key scenario. They don’t explicitly restrict themselves to pages, or data, but they do help identify the user’s view of what is happening when they interact with the system – and give insight into the user’s experience over time.
Personally I’ve used mockups, high fidelity design, conversation/whiteboarding and acceptance tests to varying levels of success. One of the problems you face in Agile development is that the more artifacts you ask for, the longer it takes to go from designing to building – and the greater the chance that your artifacts are out of date and, frankly, wrong.
I’m still not sure about how to set my user stories, I sure appreciate the discipline they grant even quick feature specifications, but I’m loathe now to simply bang them out when the reality is that I might need to use either less, or more, detail for a given feature. I’m going to keep experimenting because that’s what Agile is all about. In the meantime let me know if you find something better to use!
