In an article from January 2011, McKinsey outlines a series of ten tests to validate your current strategy:

Summary of the tests:

1. Will your strategy beat the market?
2. Does your strategy tap a true source of advantage?
3. Is your strategy granular about where to compete?
4. Does your strategy put you ahead of trends?
5. Does your strategy rest on privileged insights?
6. Does your strategy embrace uncertainty?
7. Does your strategy balance commitment and flexibility?
8. Is your strategy contaminated by bias?
9. Is there conviction to act on your strategy?
10. Have you translated your strategy into an action plan?

Each test includes a more detailed description, and an example of a company or industry where it is particularly relevant. There are also links through to relevant articles or books.

Although aimed at corporate strategy, this is an interesting list of points to consider at a personal or project level as well.

Kanban is a scheduling system for work items that I’m exploring further.

I heard about it from several sources, but didn’t focus my attention until earlier this year.

I highly recommend Kanban by David J Anderson. He is someone who is a practitioner as well as an author, which really helps in his explanations.

His book is broken up into four sections:

• Introduction
• Benefits of Kanban
• Implementing Kanban
• Making improvements

Each section is filled with references to industry theory, both in software and manufacturing, and liberally sprinkled with case studies from his own companies.

One part that really resonated with me is that introducing Kanban layers over the top of an existing development process. That is, you do not need to change your current process. Instead, the focus is on scheduling the work that goes into the process.

This makes Kanban a logical fit for processes such as Agile, as well as more traditional iterative or even waterfall development projects.

From the book:

Kanban is an approach that drives change by optimizing your existing process. The essence of starting with Kanban is to change as little as possible. You must resist the temptation to change workflow, job titles, roles and responsibilities, and specific working practices. Everything from which the team members and other partners, participants, and stakeholders derive their self-esteem, professional pride, and ego should be left unchanged.

The main target of change will be the quantity of WIP and the interface to and interaction with upstream and downstream parts of your business. So you must work with your team to map the value stream as it exists. Try not to change it or invent it in an idealistic fashion

As with any new area of knowledge, I feel like I’ve only scratched the surface. The interesting part is the range of topics to explore further, such as Deming’s writing.

It is also helpful to be working with teams that have already implemented many of the techniques from Kanban process, and to hear first hand stories of their implementation.

One of the challenges in running a successful agile project is having a strong product owner.

In learning about agile processes, this is an area I haven’t read much about. This recent article on the Scrum Alliance site is a valuable addition and thinking about how to build a better product owner.

Some quotes:

Creating any product can be challenge. With a product being developed at the speed of agility, these challenges increase.

What teams need most is a product owner who is able to prioritize the product backlog.

It’s the product owner’s responsibility to know and communicate a product vision for the team. Knowing where you want to go enables you to reach your destination; the details of getting there we all discover along the way.

Product owners must be able to earn the respect of the team, resolve conflicts through conversations, and adjust priorities accordingly. There are whole books dedicated to managing conflicts. Learning when to take a stand and when to give is important. It is more important, though, that everyone has a voice.

Be concerned about creating a stable environment for the team members to learn and contribute. It’s imperative that you keep the team from being distracted.

The product owner is not a dictated hierarchy, but a service role. The customer, the team, and the company are all tuned around the product by the product owner.

It is worth reading in full.

Presentation from the authors of the book “Agile Retrospectives - Making Good Teams Great” at Google. Lots of great tips on how to improve your sprint & project retrospectives.

One tip I picked up on was to ask “how was the energy for this sprint?” rather than the bland “how are you feeling?”.

Their structure for a retrospective is:

• Set the Stage
• Gather Data
• Generate Insights
• Decide What to Do
• Close the Retrospective

The way to succeed with a process such as agile is through continuous improvement. The forum for reviewing what needs to be improved and to decide on how to improve things is the sprint retrospectives.

Retrospectives are critical for having a successful project.

Joseph Pine’s talk at TED really has me thinking.

This is a table outlining the difference between the types of economic output, using the example of coffee.

The drive to software-as-a-service makes the software industry jump to service. It takes Apple to move it to an experience. Disney is another example of experience based economics.

I like this framework for thinking about what business I am working in. The trick will be to figure out how move up the ladder to render an authentic experience.

His book is now on my to-read list.