The XP2000 conference series grew out of the great interest in Extreme Programming, XP. At the time, the XP practices seemed daunting. There was the Planning Game. We had to convince the boss that we should Pair Program, construct everything with the support of Test-Driven Development, and Continuously Integrate everything into a working system.

There were 12 practices in the XP tool set first formulated by Kent Beck, Ron Jeffries, Martin Fowler and their teams. Then we added Norm Kerth’s Retrospectives.

It was a minimalist set, but it was still too challenging to implement even that for many organizations. Agile adoption did not really take off until someone figured out how to target the training budget of low-level management instead of the hearts and souls of honest programmers.

Not all agile adoption went in the direction of mass mediocrity. Some people went the other way, and made Extreme Programming even more extreme. They said we should not only integrate all the time we should deploy and deliver all the time, Continuous Delivery/Deployment.

Then, thanks to insights from Lean and legendary fighter pilot and strategist John Boyd, came a revolution in the product owner/XP customer’s work. Lectures by Steve Blank inspired Eric Ries at IMVU to apply Boyds OODA-loop to agile product definition and management.

I did not believe it at first, when I heard how those insights brought great success to an agile product company, IMVU. They aimed to carve out a market share alongside the big game companies by doing a virtual world game. “Who needs another one of those?” I thought.

I changed my mind when I saw a picture of their development team a few years ago. (http://flic.kr/p/5nGFan) The picture was from the IMVU Mohawk day. The team had promised to cut and dye their hair like a character in their own game if they ever made a million a month. Lets just say they looked like the eccentric million dollar rain makers they were. I’ll never forget those mohawks…

Today, IMVU is one of the largest 3D chat and dress up communities, with 3 million active users each month. There is a total of about 50 million registered users. As a comparsion, Sims by Electonic Arts has sold 16 million copies worldwide. If IMVU was a country, its population would be more than five times that of Sweden.

IMVU clearly has outstanding employees, which usually is something venture capitalists care far more about than methodology. But one vital part of the IMVU success story was that Eric Ries, one of several full-throttle extreme XP practitioners at IMVU, went to a class at Stanford on how to define yourself in a market as a startup.

Silicon Valley veteran Steve Blank gave lectures at several universites on how a startup or new technology needs to maneuver like a fighter pilot not only to survive but to prosper. Steve Blank has written a few books on the market side of high-tech startups and Eric Ries recently came out with his own book titled The Lean Startup.

At XP2011 in Madrid there was a lot of interest in Lean Startup practices and experiences. We’d like to listen to your Lean Startup stories at XP2012.

Eric Ries and Steve Blank focus on the startup scene, but a lot of what Lean Startups do is highly relevant to any software-dependent industry.

We would be delighted to hear about similar combinations of an extremely disciplined agile continuous delivery driven process that is directed by Lean methods like the OODA applied to product management and market positioning.

Both startups and established industry are invited to share, teach, master insights on Lean Startup models at XP2012!

OK, lets assume that like in the article “Mature Agility – Where Are Your Agile Riffs?” that you have a working agile process.

Why is there still “analysis paralysis”, requirements trashing and treadmill effects in your supposedly smooth agile projects? Why is everyone thinking inside the box of their usual pet technology?

Is everyone so busy running in sprints that they can’t stop to get the bicycle off their back and get on wheels instead?

Even worse: Maybe there isn’t any bicycle on their back.

Many companies hold innovation contests. But that is just cashing checks from the bank. What do they do to enable people to be innovative ?

Well some companies allow their staff to play with technology: XP2012 did a workshop with “Sveriges Ingenjörer” (The Swedish Association of Graduate Engineers) a while ago on Agile and Tech Play. One speaker, Ulf Månsson, talked about how his employer sponsored “Nerd Lunches” where engineers got a free lunch and it was OK to learn, play, brainstorm and innovate around a theme. The only rule: The theme should NOT be selected on business value. Sometimes they played with jumping Lego pieces. Why did the employer sponsor this? Well: Often enough, sometime after a nerd lunch with a theme, that had no business value at the time, people got inspired to play a little bit more with something on their own time. And even later some client showed up with a request for some new unexpected project where some nerd lunch theme would solve a problem. The guys with nerd lunches had already played with some stuff and knew how to do it. All the competitors could only offer billable working hours investigating possible solutions. Simply put: The company who sponsored nerd lunches, ie allowed people to be curious and play in a timebox with stuff outside the current business focus, for their engineers won more bids than their competitors.

Another speaker talked about exciting stuff like Makerbot, RepRap and other do-it-yourself 3D-printers and stuff.

Someone gave a talk on Arduino and how that makes hardware and embedded software accessible to people with product that usually don’t do either electronics or software design.

At XP2012 we like to hear stories about how you and people you know put ideas and solutionas up your sleeve to be able to fulfill the promise of Agile!

Let’s see: You have a great customer/product owner. Your team masters the agile planning game. You create all code through TDD – like a rock climber puts in spikes, even in your sleep. Refactor like a chef keeps the kitchen tidy to be able to serve all the time. You and your team communicate through tests with each other and the customer/product owner. Your team is addressed like a single person. It was a long time since you needed anything transitional guidance or middleman like a scrum master. The continuous integration and delivery infrastructure is up to date. You never put you hand in the patients stomach without another surgeon standing by, that is you pair program all production code. All spikes are done as unit tests. The team communicates with tests. Teams communicate with tests and tree-like capability graphs with post-it’s on a whiteboard and master how to coordinate and build large systems with multiple agile teams.

Great!

But what about the stuff you actually need to DO THINGS with all this agility? Do you have pieces enough to solve any puzzle that is thrown at you? How do you hone your skills? Do you go to Coders Dojos? DO you practice Code katas? Do you learn (from) a new programming language every year? How often do you just read code from some other project to learn? Have you ever reverse engineered some piece of technology, hard- or software? (More on this in What’s Up Your Sleeve?)

People often expect agile teams to be flexible, innovate, well agile. We are supposed to catch anything that gets thown at us. To Improvise and Adapt. Like Theatresports (http://en.wikipedia.org/wiki/Theatresports) where a team with actors are challenged with a theme they are supposed to improvise around. The best team wins. How do they do that successfully, and in front of an audience? Without any rehearsal? They use “riffs” to build their on-the-spot improvisations.

Riff is originally a musical term that was allegedly coined by the legendary American jazz saxophonist Charlie Parker. (Parker recorded “Thriving on a Riff” in 1949)

A riff is something well-defined that you can practice and master but with loose ends that you can splice together with something else. Music is mathematical and precise, yet a medium of flexibility and emotion. Riffs in music is well-defined patterns and building blocks and the improvisation is how they are spliced and blended. The same goes for improvisational theatre.

So the next agile planning session when your agile team is expected to be innovative and able to improvise with a high-quality result: Where are your agile riffs?

One aspect of agile riffs is of course to master software craftsmanship like TDD, refactoring, continuous deployment, apir work, etc. But you also need to be curious on how things are built. Like a jazz musician that digs numerous other jazz performances instead of just practicing by myself. Katas in great but you need influences. The alternative is some Agile Duel of The Banjos.

Note: This is not about the minor training and services industry has grown around diverse methodology certifications.

AT XP2012 we have a growing and active industry reference group that gives us input on what is relevant to “end-users” of agile. Agile conferences always have a large presence of trainers and consultants. We like to make the “end-users” participation much stronger.

The industry companies that actively participate in the preparations of XP2012 are from major industries like telecom, industrial control, medical devices, aerospace, etc. These companies do products where software is a major ingredient. Consider a modern truck from Volvo Trucks: About 70% of everything that is added value in a new model is driven by software. The ability to innovate and adapt while developing embedded, often safety-critical, software systems is very attractive to the automotive industry.

Ericsson presented at a Lean conference 2008 that they won major bids by being able to deliver updated functionality within weeks of the customers launch date for a new technology. The customer could be first out without any penalty. Usually the first one who invests in a new telecom technology will be at an disadvantage. Usually it is the second or third adopter that will get the benefits even if they buy the technology from another vendor. Why is that? It is not about ironing out bugs. It is about what you learn about what subscriber base actually wants when you release a new technology into actual use by paying customers not just focus groups. The other telecom suppliers, and Ericsson in the past, could not get a new system release out the door in less than 6-12 months. With agile, Ericsson won bids because they showed that agile teams working in two-week iterations could deliver functionality every two weeks. It has been possible in the past as well, by ivoking “escalations” that gather crash teams of key resources to save the day. The problem with escalations is that all normal operations suffer since they are robbed of key personnel. What impressed Eriksson’s telco customers was that it was the regular organization, in the form of mature agile teams, that delivered, not a crash team that would hurt all other ongoing projects, some of them with the same customer.

Agile teams at XP2012 will build industrial grade software for military jet fighters. That is agile in a safety-critical embedded environment.

We look forward to more conference submissions on agile in safety-critical and embedded development!

Where Simple Design Counts

I myself took an industrial class in safety-critical systems development in the mid-90s by professor Nancy Leveson , author of the instant classic Safeware, on proven methods to build safe systems, why they work and why you need them. That class taught me a number of methods that you also find in Lean, e g root cause analysis. But it also gave me a very strong rationale for simplifying code and how to make it robust and maintainable. I still remember how professor Leveson told the story on how she and her researchers got to review the control software for a nuclear facility. They were able to show that they could make the software much safer by removing roughly 50% of the code. Some of the code would never execute since it checked things that was already ahnled in hardware, like faulty memory cells that was checked with parity-checked hardware.

I brought with me these Safeware-lessons about simplicity, understanding bigger the system and being discplined as a coder to my first XP teams I like to think that this contributed to make even my first XP team a huge success back in 2000.

Back in the early days XP and Agile in general was perceived as undisciplined sloppy development. Some people might still pull off such crap under the guise of Agile.

But I think most of us has discovered that simplifying code and being disciplined is instantly rewarded, more so in an agile than in a traditional workflow.

 

At a conference about software development, wouldn’t it be useful to have some people there actually develop software? We want to invite you to bring your whole team, and show off how agile you are. Set up your team information radiators, pair programming stations and servers, and spend part of the
conference actually developing your product! With any luck, some of the excellent agilists at the conference will come and pair with you.

The only rules are that you must be agile, and you must deploy into production during the conference. If you deploy several times a day and the product is generally available for conference delegates to use and try the new features, all the better. 🙂

See this as a challenge for your team. If you’re going to be able to show your process off to a whole conference of agilists, wouldn’t you like to have the best possible process? Wouldn’t you like all your team members to work effectively with the latest tools and techniques? Wouldn’t the challenge of having to be ready to show off what you can do at XP2012 be a great way to motivate your team to improve over the next 6 months?

This is the challenge that the team behind http://blocket.se (one of Sweden’s biggest ecommerce sites), and a team from SAAB Gripen, (software for jet fighters), have already accepted. Will you join them, and take up the XP2012
team challenge?

Deliberately going Agile

Ten years ago we all hoped for Agile to get a big breakthrough to make our software, our products, our work-life, so much better. Well Agile took off, eventually, but too often just to get the Agile Checkmark™ and then go about the business as usual. Regardless of agile methodology, we have all seen random acts of agile. We need better ways to design for large scale agile transitions than putting “Agile” on business scorecards that propagate down in organizations without proper rationale. Cargo Cult Agile is no laughing matter. We need to do much better! It is not enough to claim that everyone has misinterpreted my favorite agile method but if you hire me, all the good things will come to you. We need to understand human nature especially in crowds in order to Go Agile by Design

Agile & Design – A Personal Story

Many people perceive design phases as overhead, a reaction against waterfall approaches where people without any experience of classical design work where supposed to “design” requirements and technical blueprints.

My own early experiences with design and agility were quite different. At the age of 17 I got some minor recognition as a hobbyist inventor. It was enough to land me an apprenticeship with a small innovation bureau in 1981. Three people in the core team: An industrial designer/art director, an electronics engineer/sales guy, and a programmer/digital hardware designer.

It was a profound and life-shaping experience:

1. Meeting with a customer on a Wednesday or Thursday. The industrial designer sketched continuously, much like I later learned that legendary IDEO™ does. It usually took just one meeting to get very far on a collaborative design with the customer. The flexibility of pen and paper is still hard to beat with design software when the hand that holds the pen is skilled,
2. If the design felt evolved enough to both designer and customer, the core team had a brain storming on how to make a working prototype in a week. Sometimes it was just a 3D model cut out of cardboard, but often an embedded product that started out with a high-finish 3D-model but in this stage dependent on some umbilical to drive the electronics from a desktop computer.
3. The designer took off to a prototype shop 2 hours’ drive up north over the weekend and built a 3D-model of whatever we designed together with the customer. Usually in wood that was painted to look like other materials. Remember there was no 3D printers generally available a back in 1981.
4. I the meantime, while the designer was busy with the 3D prototype, the electronics and the software guys started to build software and interfaces that would give the product life in just a few days.
5. The customer came back the next Tuesday and saw a live prototype where working software often was key, although often driven by some umbilical to a desktop microcomputer since off-the-shelf Arduinos was not available 30 years ago.

I was grateful just to hang around these guys, but I sometimes also got to do some small contributions. This also set me a standard that made it hard to take a most methodology “design phases” seriously.

We have yet to see a CAD- system that beat a skilled hand with pen and paper. You claim otherwise? Sure, most people think that something form Autocad or maybe the design tools from Adobe can berat pen and paper, hands down. Right and Wrong, actually. Once you have a something like a base design a graphics profile or similar design baseline, tools like CAD programs or vector graphics can save time as long as you are producing VARIANTS of one baseline. But if you want to quickly cover a large solution space brain-storming style, nothing beats a skilled designer quickly churning out vastly different visualization of diverse ideas with pen and paper. The cost of building a 2D or 3D representation, a model in most graphical programs is far slower each time. The difference in commitment to a particular solution between a few quick strokes with a pen and setting up some hi-fi design preview is HUGE.

Another thing I learned from these early days is that a industrial designer needs to be interested in how stuffs are made. An industrial designer needs to be curious of how many different things are put together and what makes them work. In the field of software we have seen inroads from industrial design into usability and from house architecture we got design patters. The design patters movement actually was an incubator for the agile movement.

Actually, most people have never experienced how real designers work and thus, another case of Cargo Cult. http://en.wikipedia.org/wiki/Cargo_cult.
(Don’t miss the excellent video on Cargo Cult at http://www.youtube.com/watch?v=qmlYe2KS0-Y )

The following almost 20 years, I suffered through cargo-cult “design activities” and a lot of other, to me, counter-intuitive practices and processes that made software painful and slow to develop.

But XP and Agile felt like getting back home to that core team in that small innovation bureau.

The best Agile teams, to me, act like a skilled industrial designer with pen and paper. They can quickly explore a large solution space to find the best solution without spending too much upfront effort. Between the team members, they know about a plethora of solutions to throw at a wide variety of problems. We go deeper into the topic of having solutions in store in another artice on Makers, Tinkering, et al at XP2012.

For now: Lets go Agile – by Design!
Erik Lundh
General Chair
XP2012 -Agile by Design
The original Agile/Lean conference since 2000.
May 21-25, 2012 in Malmö Sweden

The XP2012 logo is designed by Åke Karlsson, the very same industrial designer that gave me my first shot at professional product development 30 years ago. You can watch the stop motion of how Åke works that we shot in April 2011 to illustrate my announcement of xp2012 in Madrid at xp2011: http://xp2012.org/video .

The rig was designed and built by Erik with inexpensive material that was repurposed. The Canon EOS50D DSLR was operated by Åke himself at his own leisure. Erik built a foot-operated focus and trigger remote for the camera with electrical piano pedals from Yamaha. The piano pedals were NC when the camera needed NO, but I did not need anything more sophisticated than a few relays in a box to solve that. Åke could check that his work was in camera by looking to his right on a big flat-screen panel that was connected to the cameras HDMI output.