My interpretation of this principle is that empowering a team allows them to create beyond your expectations. One oft-overlooked empowerment tool is the User Persona. Here is an example developed by our User Experience team:

I’ve heard of this User Persona…

A user persona is simply a portrait of the user who is behind the current set of User Stories, or who inspired an Epic. It can be as simple as a sketch, name, occupation, and primary motivation, or as complex as a two-page biographical breakdown with full color glossies and cultural implications. The most important thing for your developers is that they have a clear guide to WHO they are developing for.

Why is a User Persona important?

Developers are smart and user savvy. By understanding the source of the need and the destination of their code, they will write a better application. They may anticipate more needs than the product owner or stakeholders could interpret for them through a User Story. More perspectives on the same need usually produce better results. Also, developers appreciate the freedom and insight that comes with direct access to the primary source material, the user. It’s simply empowering.

How do I develop a User Persona?

There are a few ways to develop a persona. The simplest way is to ask those who have gathered requirements or are working on the user interface, or, if they’ve already developed them, marketing product managers. The user persona is a foundation-builder for those disciplines. You must match those personas to the current work stream and keep them relevant.

The next best way is to gather stakeholders, content strategists, UX developers and product owners together in a room with a stack of magazines and a whiteboard.  Then, agree on some simple personas for the current release or the next leg of the roadmap.  Each should include, at minimum:

• A face: from magazines, image searches, or drawn by hand – a clear, understandable face that represents the user
• A name: for easier reference and to develop affinity
• An occupation
• What they would use the tool for
• How they would use it
• Where they would use it

How do I get the team to pay attention to the User Persona?

All information radiators should be clearly visible from almost anywhere in the development room. Whether you use whiteboards, digital screens or post-it notes on drywall, the user persona should be easy to read from 4 feet away. Also, make the personas easy to replace. It’s important to stay relevant to the current backlog.

At Fusion, we spend a great deal of time thinking about the user. From requirements to design and ultimately to testing, we focus on the user. With clearly posted, relevant user personas, your developers will be empowered to create beyond your expectations.

SOUND OFF: Are you using user personas already? Do you think they are working?  Have other questions? As always, please let us know what you think!

Do you already use Agile?

If so, make sure you discuss your methodology completely with the consultant, including which roles you expect them to fill. Agile methodologies vary widely, even those that fall under scrum.

If not, reconsider making a consulting project your first agile experience. The tools, vernacular and—more importantly—measures of success that you are accustomed to will likely be quite different. Don’t undervalue the debt of taking on a new methodology along with on-boarding a consultant.

Do you need an Agile coach?

If your team is new to agile, or if the consultant is taking on a leadership role within a relatively new agile team, you should seriously consider budgeting for agile coaching. Agile coaches help the organization understand the outputs and benefits of an agile project while helping the team transition to the new, highly transparent way of working together.

Do you have the time to be the chicken?

Regardless of role, YOU are an integral part of an agile project.

Stakeholders Can Expect: (at least)

• Weekly meetings
• A ping every other day to vet a concept or a solution on your user story
• To provide user stories
• To elect and champion a product owner that you trust

Product Owners Can Expect: (at least)

• Daily meetings
• Owning and prioritizing the backlog
• Attending the first part of planning meetings
• Facilitating sprint demonstration and retrospective meetings
• Daily interaction and availability to the development team
• Being called upon by the scrum master to help knock down barrier
• To provide user stories
• To elect and champion a scrum master you can trust

Does the budget support it?

Agile deliverables are minimum scope plus whatever value the development team built into them.

Is the project fixed bid? Consider going for a fixed bid of the minimum, critical scope only and handle any subsequent iteration as a “per iteration” cost. They can quote you on per iteration as long as they know the time box for your release cycle. Fixed bid for a vague scope rarely works well for either party. Fixed bid for “anything it takes to make me happy” is a waterfall approach and not an agile approach. Agile emphasizes redirecting resources flexibly to provide the best, most timely solution for the most urgent needs.

Consider instead a ‘per iteration’ bid. The consultant should, if they have an agile team that has worked together before, be able to estimate pretty fairly how much they can get done per iteration.

Do your release mechanisms and policies support it?

Quality and compliance are usually where complications occur. If you have a standard process that diverts your code through a week of QA and testing—you probably aren’t ready for this. Agile requires consistent and constant release, even if it’s every three weeks.

If your testing and quality/compliance gateways are baked into your development process then you’re in better shape.  Automated testing, TDD and a the product owner and scrum master addressing the external quality and compliance barriers are also to your benefit. I’m not saying you cannot do agile without baked-in quality, but it’s very difficult, and you should standardize the way you accomplish your compliance and quality needs before you bring in a consultant to do an agile project.

Can you tolerate imperfection?

Agile delivers solutions in small, incremental pieces. That means releasing something basic, rather than waiting until it’s complete with all of the features your customers want. Features are added through iteration. This allows you to react to the response to the release and adjust the next features accordingly.

Agile often delivers a greater number of defects unless a TDD solution is also applied. Not all defects are considered sacred and a priority simply because they are defects. If an enhancement is more important to the users and the defect is not critical, it will often wait.

What role do you want your consulting partner to play?

As a (user type/persona), I want to (insert desired action) so I can (insert revolutionary motivation here).

Without users to provide feedback, and without a product for anyone to provide feedback on, how do you address the issue of User Stories?

It’s Not Just Requirements

It’s tempting to slip back into a requirements mentality with a prototype.  Don’t do it!  You’ll miss all the benefits of that last half of the user story: “so I can (insert revolutionary motivation here).”  Requirements usually – and rightly – provide specific technical, compliance, and integration direction for whatever you are building.  You need those things in prototype or new product development.  You also need real User Stories and you need them before you design and engage in release planning.

What Should We Bring to Release Planning?

There are different beliefs on Iteration Zero, whether it does or should exist.  For convenience, let’s call whatever you do before your first release planning session iteration zero.  Here’s what you need to gather:

• Compliance Requirements – These usually come from your product owner, company SME or, if you’re lucky, a compliance and quality lead from your team.  These requirements usually already exist and cover all your applications and projects.
• Integration Requirements – This set usually comes from your technical lead and system administrator, both of whom will understand, based on a high level charter, how and where the new prototype will need to fit into existing systems. 
• Charter – This usually comes from the product owner.  It is a result of the Product Owner’s being a liaison with the company/sponsors before the project team even sees the work.  Charters should contain the high level goals of the application or prototype, the types of customers it serves, basic expectations around its release and performance, and authorization to do the work.
• User Stories – How do you get them?  It’s not as difficult as you think.

Gather Investors and Get Their Stories

Every project has parties interested in the company.  The Product Owner can educate them on the need and the format of a User Story.  In most cases, a Marketing/Product Manager, Sales Representative, Customer Champion, or Customer Service Representative can provide you with a starting list of user stories that cover basic functionality.  The Product Owner will have a harder time prioritizing and pruning user stories from these highly-invested “customers,” but it’s part of a Product Owner’s role to make the hard decisions about what the “thing” should do first, most and best.

In short, when there are no users, talk to people closest to the users for whom your work is intended.  Keep the list short and make it just enough to get to production.  You’ll be able to provide true user stories soon enough!

Really WORK in GitHub – Huboard

I recently explored an application that displays GitHub issues and defects, as well as pull requests, from your repositories in Kanban work board format. In this post we will refer to a Kanban Board, NOT the Kanban methodology. A Kanban Board is just an information radiator that shows where the work is in the development cycle. The Heroku application, Huboard,  has pros and cons for an agile project team, but overall can provide a lightweight, easily adopted solution to managing a sprint backlog for a distributed team.

 What Huboard DOES

• Provides a virtual agile work board WITHIN GitHub. No plugins or bridges to other applications.  Everything is right there.
• Allows you to decide what work will show up on the board. Work begins in the backlog by default OR you use a feature that allows you to designate what goes on the board. This keeps things clean.
• Allows you to define work stage columns with any name you desire. Backlog is hidden behind the left arrow and appears when clicked.
• Uses GitHub labels and milestones. Those work “stages” are labels in the GitHub repos. You can apply them to almost anything and still use labels the way you used to within GitHub. Milestones provide an easy view on the left-hand side of how work is categorized. This is particularly useful for epics.
• Updates with drag and drop. In the Kanban board view you can drag and drop work into different columns, updating the labels within GitHub.
• Allows access to the GitHub issue directly by clicking the #Number from the Huboard view.
• Honors user permissions. Users only see issues for repos they have permissions for, even if more repos are connected to that Huboard.
• Shows multiple repos on one Huboard. An organization can show all or a few select repos on a Huboard.
• Provides basic, high-level progress on issues at the milestone level.
• Has an active and responsive developer, RaughRyan, in Austin, Texas. I submitted several requests that were entirely project manager centric. Although Huboard’s current user base is mostly developers, Ryan caught the vision and responded to my issues quickly and thoroughly.
• Actively iterates. Here are a few of Ryan’s recent blog posts on Huboard that highlight its recent iterations:
  • Huboard Goes RealTime
  • Huboard New Feature Overview
  • Huboard – GitHub issues made awesome

What Huboard DOESN’T Do

• Estimation tools or mechanisms. You’ll have to find a way to do this within your issues and repos.
• Detailed metrics or reporting. Look elsewhere for that.
• Combine milestones with the same name. As a PM, I’d like to be able to combine milestones for multiple teams. For example, we use the Milestone label to denote an epic. If I have a community team working on the epic Flash training, the dev team and QA team doing the same, they all have separate repos in GitHub.  I’d like to be able to aggregate those milestones and show a progress bar from that point.  The issue is in his backlog and I’m sure he’ll get to it like he has my other feature requests.

My Humble Opinion

Would I use it again?
Yes. With an open source project or a development heavy project with a technically savvy product owner, yes. With a multi-track project with larger teams and a demand for dashboard-type reporting, then no. I’d go with a system like Sprint.ly with GitHub integration to pull requests.

Can non-developers “get it”?
Yes. The interface, once set up, is understandable and relatively intuitive. You will probably need a developer’s assistance to set it up.

How long does it take to set up?
About ten minutes.

Would I Reccomend it?
If your priority is simplicity and a digital work management tool for a distributed team, Huboard may be for you. It’s fast to set up, has a low learning curve, and will either become your Kanban board or help your team determine exactly what they do and DON’T want out of a digital work board.

Vitals Recapped

1. Overview in Plainspeak: GitHub issues made awesome
2. GitHub Project: https://github.com/rauhryan/huboard
3. Developer: https://github.com/rauhryan
4. Website: http://huboard.com/
5. Twitter: https://twitter.com/Huboard
6. Blog: http://lostechies.com/ryanrauh/author/ryanrauh/

Aside from documenting your process according to the guidelines in the previous post, our experience with local processes is very simple and can be boiled down to a few rules.

1. Decide if a process or procedure is really necessary. Really.

The first question you should ask is: Do I need this procedure to “do the right thing” and to show others in the company that we are “doing the right thing?” Generally, if it fills an unaddressed gap in global procedure, mitigates a risk identified at the Project Charter stage, or provides a wrapper for ongoing inventories of exceptions or content, it is worth it. If you are reasonably covered by existing work practices and corporate compliance requirements then think hard about adding another layer of complexity to what you maintain.  Can you be accountable and transparent with what you already have?  The exposure of social media provides much of the transparency on its own.

2. Bullets and outlines beat text.

Make the process simple enough that anyone could build the visual flow of it in their mind within a few minutes of reading it.  Succinct bullets, or better, providing the graphic guidance is preferable to using corporate speak, legalese, or excessive adverbs.  Checklists are preferable for quantitative judgments and decision diagrams are preferable for qualitative judgments.

3. The team owns it.

Ask the team executing the work if it’s worth it.  Ask those who provide compliance guidance if it is required.  Ask the person who will have to maintain it if it is worth it.  Go a step further.  Give the team the goals and ask them to WRITE it and decide where to keep it.  Have them elect the procedure owner. If the team expresses hesitation in being a part of the collaboration, you can expect the same hesitance in complying with the procedure, once established. This rule can be a deal breaker and may require facilitation by the project owner to help frame the need to the team appropriately, so they can get behind the reason for the documentation or working process.

4. Live by it

If you build it, live by it.  If you do a periodic temperature check and realize that the process is no longer useful, change it, replace it or abandon it.  Just document your decision and add it to your best practices and retrospective agenda.  You must also support your process with the right tools.  If your support software, third party applications, or even hardware don’t support the process, you will run into yet another barrier to success.  Go into the process creation process understanding that every process or procedure requires an investment for someone, the team, the owner, the document—er  nearly everyone on the team.

What we found to be worth it…

Here are a few local processes we found worth the time and effort to create and live by, as did our team.

• Pre-qualified Commenters: A process that provides the training and authorization for social media posters to be pre-qualified to speak on behalf of the team
• Developers Launch Checklist: For hosted or administered platforms a checklist to assist in ensuring corporate compliance at launch
• Blogging Style Guide: More a guideline and less a process, this document succinctly summarizes our voice and mission for our bloggers.
• Risk Assessments: We have several locally built risk assessment tools that compile corporate risk factors with those we consider important to acknowledge before a project’s launch. In short, the real and necessary risks are compiled into one or more tools for evaluation.

What you should end up with…

A library of checklists, outlines and diagrams that are easily digestible, stand on their own, and are owned and managed by the team.  If they can’t live without the project manager, they probably shouldn’t live in the first place.

Is that all?

Local processes are the last administrative aspect to “doing the right thing”.  Next time, we’ll talk about touting, the team, and how to build the team behavior that drives unity of vision and of voice.

First, Know Thyself: Expectations are everything.

Before we discuss some artifacts and practices that I’ve found valuable with other clients, I must make a disclaimer. Step One in building your documentation is to know what your company and industry requires. I probably won’t be of much help to you there. What I can give you is this advice: do an analysis before you jump in.

1. Find all the procedures and processes that are applicable to your situation.  Don’t know them?  Find the people who do (see my previous post).
2. Read the procedures and requirements.
3. Be mindful of what is required versus what is given as a recommendation.
4. Vet the expectations with your stakeholders and project owner.
   • Ensure they understand the required deliverables and artifacts
   • Build a quick RACI so they can understand the resource impact of the internal requirements.
   • Show them where these deliverables and artifacts will live, either in company established locations or a local location that will be accessed by colleagues outside your team.
5. Make a high level plan for getting it all done.  Show what has to come first, what can happen in parallel, etc.

That, of course, is an oversimplification of the process. Every company is different and two days spent in analysis and getting your stakeholders and project owner on board will go a long way to repeat success with social media projects.

Now that  I have had the chance to pass on what I consider the value in this post, how you can prove that social media can be compliant, accountable and transparent? Going above and beyond the company required documentation may be as simple as reframing one of their deliverables in a more valuable way, combining other requirements, etc. Here are some constructs I’ve found valuable in regulated industries to support launch, maintenance, and project closure.

Launch Documentation: The point is, after all, to get launched.

Build a Charter!  It should include:

• The purpose of the project – what you are doing and why you are doing it
• The tools you are using – include the platform itself as well as any add-ons, apps or third party functionality
• A team roster, with names, roles and role descriptions
• How you will measure success – be explicit about your goals, how they will be measured and to whom they will be reported
• A specific review period for the project and where review records will be held

A charter goes beyond compliance and can also be an effective way to introduce your project to the people you need to get your project launched. Sell it! Be high level for executive eyes but be explicit in covering the compliance hot spots for your industry.

Record Consensus!

Approach friendly faces in the appropriate departments (e.g. your Compliance Review Committee) and get their feedback or approval on the Terms of Use and Privacy statements for the platforms and tools you intend to use. Record the approval! If you followed any of the advice in the People installment you aren’t in this alone and the documentation should reflect that.

Content is King – Manage it with a Content Management Strategy

User generated content is possibly the hottest area in regulated industries. Be proactive—show how you will manage user generated content with a content management strategy. A simple flowchart clarifies what types of content should trigger what types of interactions. Share the strategy with those who manage regulatory compliance within your organization and get their buy-in. Record it! In general, a content management strategy should answer these questions:

• What kind of content requires additional action?
• Who is monitoring for that kind of submission?
• How frequently are they monitoring?
• What action will be taken?
  • Be clear about who, when and how.
  • Describe the content management tools and their capabilities within the chosen platform.  Do you have the ability to remove a user’s post, for example?
  • How will the action be escalated, if necessary, to the appropriate organizations within your company?
  • How will your team or the company respond?  Will they respond?

Maintenance Documentation: Be ready with an answer, any time.

Keep an Inventory

Build a simple inventory where all your social projects are stored. A best practice is to have a high-level chart with columns for each necessary artifact and a link to that artifact. Don’t make your reviewers and team scroll through endless pages of documentation to find what they need to be transparent and accountable.

Track Exceptions—anything out of ordinary expectation or operation

• Keep track of any content issues that are raised via your content management strategy and how they were resolved
• Keep track of any guest content creators
• Keep track of any service interruptions and how they were resolved

Track Success!

Keep an inventory of your goals and measures and periodically record the results. Also keep track of any cross-platform conversions. Show, for example, how many of your Facebook followers came from your Twitter Stream. Or, how a Four Square check-in drove a user to the company website. Social media is a living system and just one part of your digital presence.

Record your Local Procedures

I’ll discuss recommendations for local procedures in my next post. All procedures should be recorded along with their effective dates, review periods, and the body of the procedure.

Closing Documentation: Sometimes you have to say goodbye.

Create a Retirement Plan

Regulated industries have project closing procedures to rival any project launch. It is important to understand where the information is going, how it is stored, and how that affects your users and their privacy. Having this plan in place Before you launch exhibits vigilance.

• First understand your company’s requirements and adhere to those. See Step One.
• Describe how the platform and tools being used handle closing a profile, account, or presence.
• Describe where the content will go and where it will be stored.
• Lay out the communication process you intend to use with your users. Will you give them 15 days notice for example? Or, will users be notified after the fact?

Just Do It: and Move On

Documentation isn’t thrilling and is often associated with waste and tedium. By taking the time to analyze the true expectations and the course of action for your project you can turn documentation into a powerful tool for getting stakeholders on board, gaining a reputation for vigilance, and communicating the continuous value your social media project brings to your company.

Next , I’ll explore areas where you may want to institute a local process andshare a few processes that have worked well for me.

First and always most critical are the people who make up your internal support network.  Departments represent corporate goals and fulfill corporate needs.  Individuals can also understand and invest in your vision.  Selecting and on-boarding the right people to your governance team is crucial.  The model and roles may vary, but here is the general construct.

1. Identify an executive sponsor

Your executive sponsor should have the authority to give approval for your individual social initiatives.  This person should fit well into your company’s authorization hierarchy.  In addition to signing authority, your executive sponsor should be on board with your vision, and possibly contribute to it himself or herself.  Lastly, the executive sponsor should have a strong internal network and understand the nature of your projects well enough to recommend other internal contacts to fill some of the remaining roles of the governance model.  This role is accountable for the results of your project even if they aren’t involved in the day-to-day decisions of how to execute.

2. Compliance review committee

Compliance for the purpose of this blog series means any corporate or industry procedure, policy, or written obligation of your company to its customers and government.  For this model, compliance falls into several categories:

• Privacy – the acquisition, use, and publication of personal information
• Product Complaints – ensuring that any product feedback and complaints are reported and dealt with appropriately
• Legal – terms of use, partner contracts, legal statement review
• Marketing – branding and corporate reputation
• Purchasing – terms of engagement with partners and ensuring that partners comply with regulations

The review committee is established as a part-time entity that meets informally.  Formal gatherings and mandated meetings with formal status updates are discouraged.  One-on-one communication is strongly encouraged.

Each member is on-boarded from each department and given permission from line management to participate.  Their role is to first provide guidance before any formal requests are made to open new social spaces.  Their role expands into providing formal approvals and feedback when compliance requires it.  It is important to recognize that these individuals are brought into planning before any formal requests are made.  Use their wisdom when deciding what to do, and don’t wait until you need their signature to bring them along with you.  We strongly suggest that each member of the compliance committee have at least one personal and ongoing connection with a member of the local team. Each member of the compliance review committee should be a personal champion for your work.

 3. Team leadership

Any engagement in a social space should have input from all aspects of the internal team.  This is even more critical when the social channels focus on innovation or crowd sourcing.  We recommend the following:

• Project Owner – Someone on the team has to “own” the project.  This person is accountable to the executive sponsor and compliance review committee.  They own the internal voice.
• Compliance Lead – Titles vary but it is important to have one or more members of your team who own the understanding and interpretation of compliance regulations, policies, and procedures.  The compliance lead has all industry and corporate documentation on hand, as well as a close relationship with the compliance review committee and their collective wisdom.  It is the compliance lead’s role to be ready with an answer or know where to go find it as the local team plans new features or products.  They are the local subject matter expert (SME) and keeper of the documentation.  This person is accountable for the documentation and the connection with the compliance review committee.
• Team Lead -  Most teams already have a designated team lead.  They should be brought into the high-level discussions on social media campaigns surrounding new features or seeking customer input. Team leads have a closer view to the work and have a unique perspective on user voice and probably the greatest need to hear user voice.

4. Staff

Social channels require content.  In a regulated industry, they require carefully crafted, honest, and compliant content.  It is important that you staff your social projects to provide the content accordingly.

• Authors – We’ll discuss this at greater length in my post about local processes, but it’s important to have a group of people who can communicate freely as approved communicators without having every sentence monitored, and who can approve the content of others.  There may be company guidelines in place for this.  If not, make your own guidelines and standards.  Make them high enough to be above reproach.
• Content Creators – Social media needs content and content takes time.  Not all of your content creators need to be approved communicators.  Depending on your social project and how prolific you want to be, anticipate one to two individuals to do nothing but create content for a blog platform and one micro-blog platform.
• SMEs – Identify team members who are willing to be resources for your content creators and authors.
• Monitors – In regulated spaces, content needs to be monitored to ensure compliance.  Someone needs to have the job of actively monitoring every social project you launch.  Every project, regardless of platform, has its own goals and should be monitored accordingly.

Social media can be tremendously valuable as a personal conversation with your customer.  Regulated industries have their own set of challenges surrounding those channels, but it can be done with enthusiastic internal support.  Tune in next week when we discuss the documentation that can make social less mysterious and dangerous and more transparent and valuable.

SOUND OFF: What do you see as the right mix of people in a social media effort?

In addition to the squirming virtually every business does at the thought of public negative feedback, two-way social conversations unleash a host of privacy and compliance concerns within regulated industries.  Here are some of those very real and right concerns:

• Do we have the internal constructs and precedent to allow us to do this?
• How do we manage the challenge of user privacy?
• What if someone reports a product complaint in a social space?
• How do we staff the effort?
• How do we listen?

Over the past year or so, I’ve been privileged to help a unique team within one of our client companies create a governance model for managing the social aspects of an open innovation initiative. Although the parent company has digital policies and procedures in place, there was little precedent for social media channels and few internal subject matter experts available to provide guidance.

What we did have, however, was a great deal of cumulative experience in building an internal support structure, navigating the local and global compliance requirements, and individuals with the knowledge, contacts, and savvy to cast the vision for our goals.  With these resources in hand we set out to blaze trails and learn how we could make social spaces valuable to both our customers and the client’s organization.  At the end of a year we have a still-evolving, but successful, governance model as the foundation for all our future social projects.

Every recipe will be different as every organization is different.  Still, we believe we’ve identified some critical ingredients that should be part of any successful social media governance model:

People – individuals do work and make things happen.  You need the right people in the right roles.

Documentation – be compliant, be accountable, be transparent

Local Processes – do the right things, the prescribed things, the valuable things

Tout Strategy – keep people onboard with the right knowledge, track progress, keep proving why it’s valuable

Create Shared Momentum – get people swim in a school rather than herd them toward an answer

We dubbed our governance model The Right Thing to Do, which is the spirit of the process, as well as our intention and the goal to which we aspire. In the following series, we’ll walk through our collective insights, trials, and errors regarding building a social media governance model, beginning with People.

SOUND OFF: What regulatory barriers has your company experienced with implementing social media?