Strategy+Business magazine have released a list of the Best Business Books of 2012. You need to register to see the reviews (it's free, and well worthwhile), but here is the list itself -
Biography
Eisenhower in War and Peace (Jean Edward Smith)
Steve Jobs (Walter Isaacson)
Birdseye: The Adventures of a Curious Man (Mark Kurlansk)
Innovation
The Wide Lens: A New Strategy for Innovation (Rod Adner)
Reverse Innovation: Create Far from Home, Win Everywhere (Vijay Govindarajan and Chris Trimble)
Cloud Surfing: A New Way to Think about Risk, Innovation, Scale, and Success (Thomas M. Koulopoulos)
Organisational Culture
Productive Workplaces: Dignity, Meaning, and Community in the 21st Century: 25th Anniversary Edition (Marvin R. Weisbord)
Kill the Company: End the Status Quo, Start an Innovation Revolution (Lisa Bodell)
Talk, Inc.: How Trusted Leaders Use Conversation to Power Their Organizations (Boris Groysberg and Michael Slind)
Strategy
The New Emerging Market Multinationals: Four Strategies for Disrupting Markets and Building Brands (Amitava Chattopadhyay and Rajeev Batra, with Aysegul Ozsomer)
Pragmatic Strategy: Eastern Wisdom, Global Success (Ikujiro Nonaka and Zhichang Zhu)
Competitive Strategy: Options and Games (Benoit Chevalier-Roignant and Lenos Trigeorgis)
Marketing
Grow: How Ideals Power Growth and Profit at the World’s Greatest Companies (Jim Stengel)
Brand Real: How Smart Companies Live Their Brand Promise and Inspire Fierce Customer Loyalty (Laurence Vincent)
The Intention Economy: When Customers Take Charge (Doc Searls)
Wednesday, November 28, 2012
Culture,
Innovation
0
comments
Why You’re Not Innovating and What To Do About It
This article from GK Strategic is definitely on to something. Unfortunately, the suggested remedy is not something that fits in easily with established corporates.
This set of internal slides about the Netflix culture was recently leaked onto the net. It's very impressive...
It's no secret that many people think the Performance Review is sick. After 23 years in industry, I've heard these reviews criticised far more often than they have been praised. Most people treat them like a bit of necessary, but useless, administrative overhead. This is a great shame, as most people crave feedback. What an ironic situation!
Atlassian have bumped up against this situation, and have overhauled their performance reviews. This involves two main things -
Regarding their new approach to remuneration, I also agree. Tying bonuses to company performance gives people a real stake in the bottom line. Of course, this is not really innovative, but I think they are moving toward best practice here. I suspect you will find that people get different bonus shares as well, so perhaps it's not quite as progressive as it sounds!
Atlassian admit they are flying a bit blind with these changes. They put these changes in place nearly two years ago - I wonder if they have posted up a retrospective?
Atlassian have bumped up against this situation, and have overhauled their performance reviews. This involves two main things -
- Abolish an overall rating, and replace it with a two dimensional graph that focuses on the frequencey of "outstanding performance" and "stretching yourself".
- Abolish individual staff bonuses. People are top market dollar, and then share in a company-wide bonus if targets are met
Regarding their new approach to remuneration, I also agree. Tying bonuses to company performance gives people a real stake in the bottom line. Of course, this is not really innovative, but I think they are moving toward best practice here. I suspect you will find that people get different bonus shares as well, so perhaps it's not quite as progressive as it sounds!
Atlassian admit they are flying a bit blind with these changes. They put these changes in place nearly two years ago - I wonder if they have posted up a retrospective?
Gartner have just released their list. It includes -
- Mobile devices
- A long-term shift from native apps to Web apps as HTML5 becomes more capable
- The personal cloud replaces the notion of personal computer
- The Internet of Things
- Cloud computing
- Strategic Big Data
- Actionable Analytics
- In-memory Computing
- Virtual appliances integrated ecosystems
- Enterprise App Stores
My apologies for letting this blog lie dormant for over 3 months. I was up to my elbows in work and university at night. My subject was "Strategic Leadership for Innovation". Very interesting! But lots of work. The good news is that it gave me lots of new material. I'll try and post a bit more often over the coming months.
There has been increasing attention paid to the role of Business Analysts in the Scrum development methodology. Feedback from some early adopters of agile methodologies seemed to suggest that the role of BAs had been made redundant via the use of short feedback cycles. Certainly I can find no mention of BAs in some of the seminal agile books like "Extreme Programming" and "Agile Project Management with Scrum".
The death of Business Analysts has been greatly exaggerated. A quick google will show you that BAs with agile experience are in great demand.
Let me tell you how we use BAs with Scrum. Usually the Scrum Master meets with the Product Owner before the sprint planning meeting to "groom" the product backlog. We push that meeting back to a week or more prior to the planning meeting (we are on month long sprints) and send the BA to meet the PO.
In addition to grooming the backlog, the BA digs into each of the user stories in more detail. He then goes away and prepares a specification based on the priorities identified. This spec is usually complete by the time the sprint planning meeting occurs, and is used for estimating and after that as a development spec. Toward the end of the sprint, the BA then tests the system against the requirements.
You've probably got some questions -
The death of Business Analysts has been greatly exaggerated. A quick google will show you that BAs with agile experience are in great demand.
Let me tell you how we use BAs with Scrum. Usually the Scrum Master meets with the Product Owner before the sprint planning meeting to "groom" the product backlog. We push that meeting back to a week or more prior to the planning meeting (we are on month long sprints) and send the BA to meet the PO.
In addition to grooming the backlog, the BA digs into each of the user stories in more detail. He then goes away and prepares a specification based on the priorities identified. This spec is usually complete by the time the sprint planning meeting occurs, and is used for estimating and after that as a development spec. Toward the end of the sprint, the BA then tests the system against the requirements.
You've probably got some questions -
- How big are these sprint specs? We have four developers in one of my teams, our sprints are a month long, and the sprint spec is usually about 20 pages long.
- What's in the specs? We make use of Gherkin, and also screen prototypes done in Balsamiq. We also do acceptance criteria for each user story.
- What do programmers think of the specs? They LOVE having specs. Rather than having to ring up the PO all the time, they can just get on with the coding. When a BA is on holidays and there are no specs available, they are not happy.
- Have the specs improved the quality of what you are building? I think having specs, acceptance criteria and tests against those criteria have certainly reduced the number of bugs in the code, and stopped us going down dead ends.
- Doesn't writing specs violate a cardinal agile principle? The Agile Manifesto says that we should value working code over documentation. I agree! However, it doesn't say we should have *no* documentation, just that we shouldn't create these huge specs and spend all our time trying to keep them up to date. We don't do that. We create a spec per sprint, and it's really a disposable document, forgotten once the code has been written.
- Aren't you just describing the role of the Scrum Master? The Scrum Master certainly does requirements analysis in classic Scrum. However, I don't believe it is usually to the detail and quality that a professional BA will give you. I've also found that Scrum Masters are usually far too busy to spend time doing the requirements in detail.
- Don't you lose agility? I don't see why you would. The specs simply reflect the priorities the PO has set - they don't change them. And the specs are a guide, not a shackle - if something doesn't work out when it comes time to code, there is no problem with trying something different.
Subscribe to:
Posts (Atom)