Agile Playground and TastyCupCakes

This Agile 2008 Conference in Toronto Canada was one of the best I had ever attended.

The presentations and speakers were excellent. The conference material was well organized. And the most stress many of us felt were trying to decide which sessions to attend (a good problem to have at any conference).

One session, Agile Playground put on by Michael McCullough and Don McGreal, focused on using games to teach participants about agile. This session was excellent because it provided trainers and coaches with lots of good ideas on how to help people new to agile, experience and feel some of the practices and principles that are sometimes hard to put words too.

Not only were the speakers professional and well prepared, they were also generous enough to document many of their games on index cards participants could take away.

If you are into agile games, and are looking for ways to teach agile to colleagues, be sure to check out Michael and Don’s website.

Thanks again Michael and Don for putting on a great session.

Click here for tasty agile games

Agile Project Management Training – Sept 11, 12 Calgary

Plan the work. Work the plan.

That has been the maxim taught in project management circles for the better part of 50 years. If only it were that easy.

Reality has taught us that when we blindly following plans we:
* miss deadlines
* exceed budgets
* and disappoint our customers

There is a better way, and it works!

Agile, Scrum, Extreme Programming, and Lean Software Development.

In this course I will show you how to:
* setup
* execute
* and successfully wrap up your own agile project

We will cover:
* agile project initiation
* requirements gathering
* estimation
* planning
* iteration mechanics
* tracking
* team building
* roles and responsibilities
* dealing with resistance
* and effective project leadership

If you are looking to:
* build trust with your customers
* improve relationships with team members, and
* gain a competitive advantage in the market place

Register Now

Where

Petro-Canada Centre
150 6 Avenue SW
Calgary, Alberta

When

September 11-12, 2008

As a former agile project lead, coach and mentor at ThoughtWorks, Jonathan was spent the greater part of the last ten years collecting, and distilling the best agile project management practices from around the world.

His experiences include leading agile projects at Microsoft, British Petroleum in the UK, AMP Capital in Sydney Australia and many other companies throughout Canada, the US, England, and Australia.

Batch vs continuous flow processing

If you are at a cocktail party, and someone asks you to compare and contrast the differences between batch and continuous flowing processes, calmly lower your martini, grab the nearest table napkin, and proceed to draw the following picture:

Suppose we were in the toy car manufacturing business and there were three stages to building a car: the body, the wheels, and the paint. You decide the most optimal way to build the cars would be to batch them up into groups of ten, and send them from one stage to the next in one big batch.

If we assume it takes 1 min per car at each stage, then we would expect the following results:

Time to build first car: 21 minutes
Time to build first batch of ten: 30 minutes

Now, suppose we were to draw this picture on another napkin:

Only this time instead of manufacturing our cars in groups of ten, we build them one at a time in a one-piece continuous flow process. Were we to do this, we could expect these results:

Time to build first car: 3 minutes
Time to build first batch of ten: 12 minutes

In the continuous flow example, the first car rolled off the assembly in in 3 minutes (18 minutes faster than the batch process).

All ten cars were built in 12 minutes (an improvement of 18 minutes over the batch process).

To really impress your guests, you could then demonstrate your worldly knowledge and command of automotive history by explaining that this is precisely what Toyota figured out when it began competing with Ford’s mass production system.

Toyota realized that a continuous one-piece flow process:
* increases productivity – more cars in less time
* builds in quality – easier to spot defective parts sooner
* is more efficient – less material lying around
* reduces costs – less inventory

By this time, other party goers will have no doubt picked up on your conversation, and you will most likely be the life of the party with everyone hinged on your every word.

You could excuse yourself.
You could change topics.

Or you could pickup a copy of Jeffrey Liker’s excellent book, The Toyota Way, and prepare yourself for the next party.

The Toyota Way

Every once in a while you pick up a book you just can’t put down. This happened to me recently when I finally got around to reading The Toyota Way, by Jeffery Liker.

The Toyota Way goes deep inside the heart of the company. Jeffrey shepherds readers through the birth of the company, the development of its founding principles, and the ever so popular Toyota Production System (TPS) itself.

The book is full of stories about the birth of Lexus (Toyota exec’s basically got tired of driving European luxury cars into work everyday) and the revolutionary development of the Prius.

If there is one thing that is made apparent to me after reading this book, it is how young the agile software movement is, and how universal the Toyota principals are. They cross industry, transcend business, and could be used by many companies (more on this later).

I am also starting to appreciate how difficult it is to copy Toyota (I don’t believe you can). Toyota’s been practicing and refining these practices for over 70 years. It’s no wonder Ford and GM can’t catch these guys. It’s much more than the practices.

If you are looking for a great read, and hunger for more after reading Mary and Tom’s Implementing Lean Software Development, this book is for you.

Share, learn, and grow!

Ask tough questions

Ask tough questions at the beginning of your projects.

Why?

Because at the beginning of the project you:

• are new
• have nothing to lose
• have not spent any money
• are mostly still sane and rational, and
• have time to do something about it if you discover something you don’t like.

The beginning of a project is the time to ask those tough, uncomfortable, awareness generating questions that all too often go left unsaid because:

a) people are just being nice and are too polite to raise them, or

b) it’s still a big love in and everyone is still gazing lovingly into each other eyes.

Like all strong marriages, if you are going to build a lasting relationship with your team, and your customers, you need to start preparing for the day after the honeymoon. Start talking plainly and frankly about how you are going to address some challenges you see on the horizon.

For example, if you start hearing things like:

So you want to replace your legacy mainframe application using a junior team, with no .NET experience, no OO experience, and no agile experience. Blindfolded. Interesting ….

You think one analyst will be sufficient to produce requirements for 30 developers? Tell me more!

You want to leave testing till the end of the project, while ensuring quality is job #1. I see.

If I understand you correctly, scope is fixed, budget is fixed, quality is fixed, and date is fixed. All we need to do is follow this 5 year Gantt chart and we will be successful? Is that correct?

Waiting to have frank discussions about these and other project pitfalls till the end of the project is too late. No one will want to hear it.

Raise issues early. Have frank, respectful discussions. And talk about these things while you are sane.

Don’t expect to resolve everything.

But have the conversation.

Bloomberg on Agile Part II (Risk Analysis)

Continuing on the theme of sharing agile project management techniques in the wild, here is another example of Bloomberg’s approach to risk management and planning. For Part I (on the benefits of working from a heap) click here.

As quoted from his book, Bloomberg by Bloomberg:

Don’t think, however, that planning and analysis have no place in achieving success. Quite the contrary. Use them, just don’t have them use you. Plan things out and work through real-life scenarios selecting from the opportunities currently available. Just don’t waste effort worrying about an infinite number of down-the-road possibilities, most of which will never materialize.

Think logically and dispassionately about what you’d like to do. Work out all the steps of the process – the entire what, when, where, why, and how. Then, sit down after you are absolutely positive you know it cold, and write it out. There’s an old saying, “If you can’t write it , you don’t know it.” Try it. The first paragraph invariably stops you short. “Now why did we want this particular thing?” you’ll find yourself asking. “Where did we think the resources would come from?” “And what makes us think others – the suppliers, the customers, and potential rivals – are going to cooperate?” On and on, you’ll find yourself asking the most basic questions you hadn’t focused on before taking pen to paper.

As you discover you don’t know it all, force yourself to address the things you forget, ignored, underestimated, or glossed over. Write them out for a doubting stranger who doesn’t come with the confidence in the project’s utility – and who, unlike your spouse, parent, sibling, or child, doesn’t have a vested interest in keeping you happy. Make sure your written description follows, from beginning to end, in a logical, complete, doable, path.

Then tear up the paper.

That’s right, rip it up. You’ve done the analysis. You’ve found enough holes in the plan to drive your hoped-for Bentley automobile through repeatedly. You’ve planned for myriad what-if scenarios. You’ve presented your ideas to others. You’ve even mapped out the first few steps.

But the real world throws curve balls and sliders every day, as well as the fastballs you practice against. You’ll inevitable face problems different from the ones you anticipated. Sometimes you’ll gave to “zig” when the blue print says “zag”. You don’t want to detailed, inflexible plan getting in the way when you have to respond instantly. By now, you either know what you can know – or you don’t and never will. As to the rest, take it as it comes.

I like Bloomberg’s approach to risk analysis and mitigation. Worry about the stuff you can handle, and don’t sweat the rest.

You are always going to be able to find reasons for not going forward with a project. And you can rest assured your plan won’t have events like loose lead programmer here, or have primary customer be poached by competitor here (both of which have happened to me). You just gotta deal with it and move on.

As the lord’s serenity prayer says:

Grant me the serenity to accept the things I cannot change,
The courage to change the things I can,
And the wisdom to know the difference.

Bloomberg on Agile

Bloomberg by
Bloomberg

A couple months ago I got tired of hearing Michael Bloomberg’s name and not know much about the guy. So, over Christmas I went out and picked up a copy of Bloomberg by Bloomberg – a self styled autobiography.

Turns out Bloomberg is a pretty interesting guy. Before becoming mayor of New York, he was a partner at the now defunct Salomon Brothers on Wall Street. After being let go (with a severance of $10 Million), Bloomberg went out and started up his own financial information company. Thus was born the Bloomberg terminal (a dedicated computer for bringing stock and bond traders market information rapidly). To make a long story short, Bloomberg did very well, and almost ran for president this year.

So what does all of this have to do with agile?

Read the following passage from the book, and observe the parallels with agile in how Bloomberg handles classic too much to do, and not enough time problem.

In computer terms, doing it whenever needed, on the fly, is working from a “heap”, not a “stack” or a “queue.” Working from stacks and queues is the rigid, bureaucratized method of operating; it makes you take out things in a pre-described order (i.e. last in, first out for a stack). But if you work from a heap, where input and output are independent, you can use your head, selecting what you need, when you need it, based on outside criteria that are always changing (e.g., what’s need now, such as responding immediately to a customer complaint or getting a gift for your spouse’s birthday when that day arrives and you’ve totally forgotten).

Michael definitely gets it. He knows things won’t go according to plan. He intuitively understands that priorities are going to change. And he places great value in being able to respond immediately to a customer (or significant others birthday).

Something I have grown to feel over the years is agile is nothing new. If anything it is as old as time. It is a natural way of working, that people instinctively do all by themselves.

This was just another example of an entrepreneur being agile back in the 80s.

The 3 fundamental laws of software project management

I read this somewhere (can’t remember where, but I think it was DeCarlo) and it has served me well. These laws have certainly held true for every software project I have ever been on.

1. The requirements are going to change.

2. It is impossible to gather all the requirements at the beginning of a project.

3. There will always be more requirements than time and budget allow.

The best advice I ever got

I am constantly looking for examples of, and stories around leadership. It is one of those timeless topics that captures people’s imagination, and people always seem to enjoy hearing more about.

This months edition of Harvard Business Review (March 2008), I came across has a short interview with Kris Gopalakrishnan, Cofounder and CEO of Infosys Technologies ($3.1 Billion revenue, 80,000 employees).

In the interview, Kris describes the best advice he ever got on leadership from a tough, grizzled, old chain smoking physics professor while pursuing his undergraduate degree.

Between problem sets one day, the professor stopped and said, “You don’t need to worry. You’re good at this, you enjoy it, and you’re going to land on your own two feet. For now, just concentrate on your studies.” Immediately after that, Kris’s grades shot up, and he ultimately earned a place in India’s top ranked physics masters program.

At one level, my professor’s meaning was simple: Do what you love, work hard at it, and all will go well. But the specifics of his message, and the way he delivered it, go to the heart of every leader’s toughest challenge – motivating people.

I use his actions and his words as a model for spurring people on to superior performance. And I focus, just as he did, on three important things.

1. First, I constantly seek ways to get my love for this business across. When I display enthusiasm, employees are more likely to listen to what I say and draw extra energy from mine.

2. Second, in talking with employees, I seldom focus on numbers but instead on big ideas and their role.I don’t think that talking about revenue targets or market share projections will get people inspired. Instead, I try, just as my professor did, to help people imagine a future in which their unique contribution has an impact.

3. Finally, I get people to focus on the future impact of how they manage the task at hand.

A large part of Infosys’s business comes from maintaining legacy applications. On the surface this is not the most exciting of software development work. But Kris constantly finds ways of motivating employees by showing them the impact their work on many of their global clients, and the world at large.

This is a great example of leadership not by numbers, but by heart. The simple act of making people see the bigger picture, and the impact their work has on the lives of others can get the creative juices flowing and motivate us to try new things.

Kris’s job remains the same today as it did in 1981: to motivate one individual at a time.

Artful Making Part II – Prerequisite conditions for Artful Making

Continuing with my review of Artful Making, here are some things to consider when deciding whether an more industrial approach, or an artful one will better suit your needs.

I have attempted to make Rob Austin’s points (summarized) in block, with my own in clear text underneath.

Artful making (see previous post for defn) features rapid frequent iteration. This approach only makes sense when the cost of an iteration, is cheap compared to the benefits gained from the experience. If the cost of an iteration is high (as in integrated chip, or car manufacturing), you would be better off doing more upfront planning.

Here are two factors to consider in the cost of an iteration:

1. Reconfiguration Costs

Reconfiguration is doing something once, and then tweaking it ever so slightly to do something else. When you can do this cheaply you have a low reconfiguration cost. Car manufacturing doesn’t have a low reconfiguration cost. Reconfiguration of a car design would involve retooling, new equipment, and possibly changing the layout of a plant. Reconfiguration in software development can be relatively inexpensive. Theatre production arranges and rearranges the actions and interactions of the performers, also inexpensively. Hence, software development as well as other business activities can be, in this regard, more like rehearsal than like car making.

Rob is bang on with this point. It shouldn’t be any surprise that early on our industry gravitated towards industrial, or heavily planned waterfall like methods. When you program a computer with punch cards, and a run of the software takes an evening, you are naturally going to spend more time upfront getting things right.

Things are much different today. Just-in-time compilers, databases, Object Oriented design, continuous integration tools, automated regression tests have made the cost of reconfiguring software much cheaper than 40 years ago.

Agile software engineering practices (typified by XP) have low configuration costs.

2. Exploration costs

The second component of the cost of iteration is the cost of trying something that doesn’t work well enough to continue doing it. In an industrial setting, we might think of exploration costs as “scrap costs.” It’s expensive to throw away physical prototypes. When the cost of exploration is high, you want to avoid making too many throw aways. Similarly, a doctor must consider that iteration may have unacceptable impacts on patients. Software development, by contrast, routinely generates “bad” versions as a way to explore possibilities. These versions are not released and can be fixed as early as the next day. Here, too, software development is more like rehearsal than manufacturing; in theatre, there is not much lost when actors try something that doesn’t “work” because something different can be tried in the next rehearsal.

Rob quite rightly points out that agile (and software development in general) doesn’t suffer from the “scrap costs” described in car manufacturing. The scrap costs in software development are people’s time (which shouldn’t be ignored). Still the cost of exploring new designs, architectures, and patterns in software is relatively cheap, compared to the payoff that comes with a cleaner, more maintainable system that is less expensive to support.