Wednesday, May 30, 2012

Taking Happiness Seriously


In preparation for our upcoming webinar on The Happiness Metric we've been doing a lot of research into how the world's leading thinkers are addressing the issue. Earlier this Spring, the Earth Institute published the first World Happiness Report for the United Nations. It makes for fascinating reading, and underlines how important happiness is and how new science shows how we can measure and use it.

From the introduction:
Most people agree that societies should foster the happiness of their citizens. The U.S. Founding Fathers recognized the inalienable right to the pursuit of happiness. British philosophers talked about the greatest good for the greatest number. Bhutan has famously adopted the goal of Gross National Happiness (GNH) rather than Gross National Product. China champions a harmonious society.
Yet most people probably believe that happiness is in the eye of the beholder, an individual’s choice, something to be pursued individually rather than as a matter of national policy. Happiness seems far too subjective, too vague, to serve as a touchstone for a nation’s goals, much less its policy content. That indeed has been the traditional view. Yet the evidence is changing this view rapidly.
A generation of studies by psychologists, economists, pollsters, sociologists, and others has shown that happiness, though indeed a subjective experience, can be objectively measured, assessed, correlated with observable brain functions, and related to the characteristics of an individual and the society. Asking people whether they are happy, or satisfied with their lives, offers important information about the society. It can signal underlying crises or hidden strengths. It can suggest the need for change.
You can read the whole report here, it's worth it, and you can sign up for the Happiness Metric webinar, on how you can use happiness to improve you and your team's performance here.

Wednesday, May 23, 2012

Joe Justice Builds a Car in 90 Days with Scrum


Agile for me was the de facto standard. When I graduated college the first job I took was with an agile software development group. I didn’t even know it was agile, it was just the way business was done there. At that time I was writing one of the first web services for .NET 1.0. Then I was poached by a consulting firm that did Microsoft enterprise software. Agile was becoming hotter and hotter, and customers were requesting agile more and more. So for several years I never worked with anything except agile software development, I didn’t know any other method!
Some of these teams were quite large, maybe more than 50 team members, and sometimes these were distributed teams working from multiple countries at once. Again I didn’t know any other method than agile software delivery – working with the principles and values of agile, lean and scrum we found ways to co-ordinate multiple teams during larger and larger project deliveries. As these deliveries grew to multiple teams, I began to interface with more teams with hand-off points and joint deliveries. They were using some other method; it turned out to be waterfall. It was so painful, so much time was caught up in change request and a lot of it came to rely on the theatrics of the project manager to convince the client that they needed a change request. And none of the teams I was on needed to do that, the client was just aware of the current state of the project and able to re priortorize. It was very much less dramatic and as a result far more efficient.
I started studying this other method, trying to figure out what it was and why it seemed so painful. And why the people on the team I was with were excited, eager, and creative. Contrastingly, the folks on these other teams were often very depressed, quite literally, and looking forward to going home. They often needed to work week nights and weekends to meet some goal that a project manager had mentioned in passing and the client had taken to be gospel. Again I was struck by this, which didn’t happen on the teams I had been working with because it was continuously iterative and work was completed in priority order. So I began studying this in earnest. And really only discovered what agile was once I learned what waterfall was. To me again agile was just the way you did work, I was lucky enough to be born right into it. I began to become very passionate about it once I saw how concrete these differences were. And the difference wasn’t that you had a high performing, creative team just magically. But there was a creative high performing team because of a specific type of project methodology and project management approach. Once I found that it was repeatable, with different teams, and there were these set of principles that could be applied again and again to avoid teams becoming so disheartened, so 9 to 5, so pathetic, so uncreative. It became something like a personal mission for me, and I become very passionate about it.
Now at WIKISPEED, again I did not know any other way to run a project. When I was on the automotive design project and then on the ultra efficient automotive challenge the only delivery method I knew was agile, lean and scrum. It came to be incredibly effective for us. It developed a very different type of car than what is on the road now. It became a very efficient car, a very quick to develop car and a very inexpensive to maintain car. Again it is not that I set out to build an agile, lean or scrum car, I set out to make an ultra efficient car with this whole team of volunteers all over the world. As the team lead who determines the project methodology, it enabled us to have this high energy high performing team, high creativity, high velocity team, and to do so much in so much less time.

Monday, May 21, 2012

On Fighter Pilots and Product Owners

The first Scrum Team was created in 1993 at the Easel Coporation in Massachusetts. Perhaps Jeff's most careful hire, and most thorough training, was the first Product Owner. He drew on his experience as a fighter pilot in Vietnam when thinking about the role of Product Owner. He knew the Scrum Team would work on a PDCA cycle (Plan-Do-Check-Act) which came out of Deming's and Shewhart's early work on quality control. But that was good for dealing with tactical issues, but the Product Owner would be working in a more uncertain world, constantly having to stay in touch with and react to the customer, the team, and the competitive landscape. The best way he had learned to deal with an uncertain environment was taught to him as how fighter pilots had to react in combat. John Boyd's OODA loop (Observe-Orient-Decide-Act). Boyd had designed it to help officers survive during combat and defeat the enemy. As he put it in his famous briefing "Organic Design for Command and Control" the key was to:
"Operate inside adversary’s observation‑orientation‑decision‑action loops to enmesh adversary in a world of uncertainty, doubt, mistrust, confusion, disorder, fear, panic chaos … and/or fold adversary back inside himself so that he cannot cope with events/efforts as they unfold."
That seemed like exactly the type of thinking a Product Owner should have. That's how Jeff trained the first one, and how he's training them now. Jeff is offering his Certified Scrum Product Owner course at the end of the month, and basing a lot of it on Boyd's thinking.

After all, Boyd was not only a legendary fighter pilot and military thinker, he had a pretty good insight into the shortcomings of the very idea of a "Command and Control" mindset.

"C&C represents a top‑down mentality applied in a rigid or mechanical (or electrical) way that ignores as well as stifles the implicit nature of human beings to deal. with uncertainty, change, and stress. (Examples: The Battle of the Somme, Evacuation of Saigon, Mayaguez Affair, Desert I, Nifty‑Nugget and Proud Spirit C&C exercises, etc.)."
That sounds like an argument a good Product Owner would make.

Monday, May 07, 2012

HICSS-46 CALL FOR PAPERS

Get your papers ready for the January 2013 HICSS conference (in Maui)!  The Agile and Lean Organizations track will be one half day during the 4-day conference. HICSS is a conference with a wide-variety of researchers (not just software) interested in system-science—how things get invented, organized and completed. You'll have many opportunities to socialize with other speakers (barbecues, beaches and good food).  The papers are IEEE published so it's a good opportunity to get your work out to the world.  I hope you can join us.

Location

Grand Wailea Maui
January 7-10, 2013 (Monday-Thursday)

Agile and Lean Organizations Mini-Track

Agile and lean approaches promote iterative product releases and pull risk-reduction earlier in product development. Characteristics include: cross-functional teams, rapid outcome testing (such as automated testing in software), continuous quality monitoring and deployment, pairing (for software, pair-programming), bias-avoiding estimation, process improvement and short feedback loops. Advocates claim agile development produces greater staff resiliency, better release forecasting, fewer product failures and more sustainable work pace.
Lean product management methods test market hypotheses and rapidly adapt to discoveries.  Characteristics include: set-based design, A-B testing, unmoderated user-experience testing, direct market experimentation, customer validation and pivoting. Advocates claim lean product management produces greater market satisfaction, deeper customer engagement, earlier discovery of hidden market opportunities, higher revenues and more efficient resource utilization.
Advocates believe that sustainably agile/lean organizations must demand technical excellence everywhere (not just in software), promote individual and organizational change, organize knowledge, train employees in agile and lean philosophies, and optimize the whole value chain from concept to cash.
We seek research papers and experience reports that describe how agile development and lean product management affect organizational systems and outcomes. How do agile development and lean product management interact? How do organizations restructure to support these philosophies? When they do not restructure, what happens? How do markets respond to rapid iterations and end-user experimentation?
HICSS conferences are devoted to the most relevant advances in the information, computer, and system sciences, and encompass developments in both theory and practice. Accepted papers may be theoretical, conceptual, tutorial or descriptive in nature. Those selected for presentation will be included in the Conference Proceedings published by the IEEE Computer Society and maintained in the IEEE Digital Library.

How to Submit a Paper

Follow Author Instructions posted on the conference web site: http://www.hicss.hawaii.edu/hicss_46/apahome46.htm.
  • Select the correct track: “Agile and Lean Organizations” or “Agile/Lean Startup Organizations”
  • HICSS papers must contain original material. They may not have been previously published, nor currently submitted elsewhere.  All submissions undergo a double-blind peer review process.
  • Abstracts are optional, but strongly recommended. You may contact the Minitrack Chair(s) for guidance or verification of content.
  • Submit a paper to only one Minitrack.  If a paper is submitted to more than one minitrack, then either paper may be rejected by either minitrack without consultation with author or other chairs. If you are not sure of the appropriate Minitrack, submit an abstract to the Track Chair(s) – see names and contact information below. for determination, and/or seek informal opinion(s) of Minitrack Chair(s) before submitting.
  • Do not author or co-author more than 5 papers.  This means that an individual may be listed as author or co-author on no more than 5 submitted papers.  Track Chairs must approve any names added after submission or acceptance on August 15.

Important 2012 Deadlines for Authors

DateDescription
June 15Submit full manuscripts for review as instructed. The review is double-blind; therefore, this initial submission must be without author names.
Aug 15Review System emails Acceptance Notices to authors. It is very important that at least one author of each accepted paper attend the conference. Therefore, all travel guarantees – including visa or your organization’s fiscal funding procedures – should begin immediately. Make sure your server accepts the review system address https://precisionconference.com/~hicss.
Sept 15SUBMIT FINAL PAPER. Add author names to your paper, and submit your Final Paper for Publication to the site provided in your Acceptance Notice.  (This URL is not public  knowledge.)
Oct 1Early Registration fee deadline. At least one author of each paper should register by this date in order secure publication in the Proceedings. Fees will increase on Oct 2 and Dec 2.
Oct 15Papers without at least one paid-in-full registered author may be deleted from the Proceedings and not scheduled for presentation; authors will be so notified by the Conference Office.
Cancellation and Refund Policy   All conference cancellation requests must be in writing.  A fee will be charged for cancellation of registration after Oct 15, at which time the paper is subject to withdrawal from the Proceedings.  There is no registration refund after Dec 1.  Cancellations for accommodations must be handled directly with the hotel.

HICSS-46 TRACK CHAIRS

Software Technology
Gul Agha  agha@cs.uiuc.edu
Rick Kazman  kazman@hawaii.edu

Agile and Lean minitrack co-chairs

Gabrielle Benefield
Evolve Beyond Limited
gbenefield@evolvebeyond.com

Dan R. Greening
Evolve Beyond LLC
dgreening@evolvebeyond.com

Sunday, May 06, 2012

ScrumPlop has Begun


Google Automation of my QA Strategy

I have consistently found in my own companies and Openview Venture Partners companies that I coach that carefully prioritized implementation of acceptance tests produces higher quality faster than anything I have seen.

An Open-E in Poland they implemented continuous integration and immediately increased the velocity of over 50 developers by 20%. The next step was to improve the quality of their open source network storage server software so it could be released faster with fewer support problems. The software had to run on 80 different hardware platforms and needed thorough acceptance testing by a quality assurance team after development had completed a release. This acceptance test phase took 4-6 weeks per release.

I told them to proritize the problems encountered by the quality assurance team and implement tests in the build process to prevent these problems from ever appearing again. After 3 weeks of work by one developer there were 130 tests were running in the build process. The next release cycle cut quality assurance to 2 weeks and reduced support calls from the field by 50% saving millions of euros of development time and generating millions of euros in increased sales. Nothing I have seen works better than this.

Google has developed a brilliant automated strategy called "Bug Prediction" which does essentially the same thing. Seems like every team should be doing something like this.


Bug Prediction at Google

What's the problem?
Here at Google, we have thousands of engineers working on our code base every day. In fact, as previously noted, 50% of the Google code base changes every month. That’s a lot of code and a lot of people. In order to ensure that our code base stays healthy, Google primarily employs unit testing and code review for all new check-ins. When a piece of code is ready for submission, not only should all the current tests pass, but new tests should also be written for any new functionality. Once the tests are green, the code reviewer swoops in to make sure that the code is doing what it is supposed to, and stamps the legendary “LGTM” (Looks Good To Me) on the submission, and the code can be checked in.

However, Googlers work every day on increasingly more complex problems, providing the features and availability that our users depend on. Some of these problems are necessarily difficult to grapple with, leading to code that is unavoidably difficult. Sometimes, that code works very well, and is deployed without incident. Other times, the code creates issues again and again, as developers try to wrestle with the problem. For the sake of this article, we'll call this second class of code “hot spots”. Perhaps a hot spot is resistant to unit testing, or maybe a very specific set of conditions can lead the code to fail. Usually, our diligent, experienced, and fearless code reviewers are able to spot any issues and resolve them. That said, we're all human, and sneaky bugs are still able to creep in. We found that it can be difficult to realize when someone is changing a hot spot versus generally harmless code. Additionally, as Google's code base and teams increase in size, it becomes more unlikely that the submitter and reviewer will even be aware that they're changing a hot spot.

In order to help identify these hot spots and warn developers, we looked at bug prediction. Bug prediction uses machine-learning and statistical analysis to try to guess whether a piece of code is potentially buggy or not, usually within some confidence range. Source-based metrics that could be used for prediction are how many lines of code, how many dependencies are required and whether those dependencies are cyclic. These can work well, but these metrics are going to flag our necessarily difficult, but otherwise innocuous code, as well as our hot spots. We're only worried about our hot spots, so how do we only find them? Well, we actually have a great, authoritative record of where code has been requiring fixes: our bug tracker and our source control commit log! The research (for example, FixCache) indicates that predicting bugs from the source history works very well, so we decided to deploy it at Google.


For details click here ...

Saturday, May 05, 2012

Agile Planning - Fighter Pilot Meets Solo Sailor

Recently I visited Hank de Velde on his boat that he uses to sail solo around the world with Rini van Solingen, original author of "The Power of Scrum." Hank and I had similar ideas on planning for high risk adventures.

Tuesday, May 01, 2012

Software in 30 Days is Out!


The official publication of "Software in 30 Days" is May 1. The book is a collaboration between the two creators of Scrum, Jeff Sutherland and Ken Schwaber. The goal of Scrum is to actually have working software at then end of each Sprint, which should be 30 days or less. Working software means tested, integrated, and ready to ship if necessary! This book shows you how it's done. It shows you how you can implement Scrum in your company, and how to improve the Agile practices you are already using. From the introduction:

We, Jeff and Ken, have been in the software industry, collectively, for seventy years. We have been software developers, managers in IT organizations and software product companies, and owners of both product companies and service organizations. More than twenty years ago, we created a process that lets organizations deliver software better. Since then we have helped hundreds of organizations do the same. Our work has spread farther than we have ever imagined possible, being put to use by millions of people. We are humbled by the extent of its adoption, and we are awed by the feats people have used it to accomplish. 
This is not the first book we have written on the topic of building software. It is, however, the first book we have written for people who do not themselves build software. This book is instead for leaders within organizations that depend on software for their survival and competitiveness. It is for leaders within organizations that can benefit from developing software rapidly, incrementally, and with the best return on investment possible. It is for leaders who face business and technological complexity that has made the delivery of software difficult. We have written this book so that these leaders can help their organizations achieve these goals, enhance their internal capabilities, improve their product offerings, and more. 
This book is for CEOs, executives, and senior managers who need their organizations to deliver better software in less time, with lower cost, with greater predictability, and with lower risk. For this audience, we have a message: You may have had negative experiences with software development in the past, but the industry has turned a corner. The software profession has radically improved its methods and its results. The uncertainty, risk, and waste to which you are accustomed are no longer par for the course. We have worked with many software organizations
that have already turned the corner; we want to help you do so, too. 
The book is available at Amazon and Barnes and Noble, in print and e-book versions. The print version is also available at Powell's.

Update: Can't believe I forgot it, if you're in the Netherlands, here's the bol.com link. Also available on Amazon.co.uk and Amazon.co.de. Thanks @scrumnl!