Future Directions for Agile

Transcript of http://www.infoq.com/presentations/Agile-Directions-David-Anderson

TO DO:

• Fix/complete first part.
• Fix ???/ inaudibles.
• Add slides.
• Put timing and texts in two-column table.

customer collaboration over contract negotiation is about trust!

got some nice slides about perfaction (rose; 16:40) and ambiguity (old lady/young; 16:43)

21:59 Refectoring isn't rework in the traditional sense, it's embracing uncertainty (change).

Individuals and interactions over processes and tools & Working software over comprehensive documentation -> Rebel against the pursuit of perfection and ask us to embrace uncertainty.

22:22 What doe pile of bananas and stack of documentation have in common? They go stale.

22:55 Knowledge work is perishable. So, refresh often. Sell out. [Picture of market salesman selling vegetables and heap of documentation]. Banansalesman understands this completely. Most business managers have no clue.

23:23 Human minds fade—must be for a reason.

23:25 Markets move: Unpredicted stock exchange crash 1929.

23: Market strategies change: Apple 1978 vs 2008.

23:38 Strategic positioning changesL Lou Gerstner

24:04 Economic conditions change (picture of special recession save 70¢.

24:19 Value is created by bringing differentiating functionality to market fastest. (Picture of swiveling iPod nano).

24:31 Lead time—from ideation to delivery is vital to business competitiveness (picture of guy holding two FedEx envelopes under arm).

24:47 And it was the recognition of the perishable nature of requirements and the business value assoicated with short cycles and fast delivery… …that led to the fourth value of the Agile Manifesto: Respondign to change over following a plan. So our movement blew up a number of myths and ended the paradigm around them.

25:14 Perfect was the enemy of good enough. And we stopped to be perfect, accepted what we had to move forward with imperfect information and refactor as we learn more. It's much cheaper, faster and better.

25:28 Self-organization (or empowerment, delegation and failure-tolerance) through adoption of a high trust culture was better than contracts, commitments, audit and arbitration in a low trust culture.

25:48 System requirements were not assets, they really were liabilities. So we spent less time writing things down, relied a lot more on tacit knowledge and focused on reducing cycle times. Absolutely the right thing to do.

26:07 What additional ideas do the principles behind the manifest offer us? (see agilemanifesto.org)

27:05 Agile recast as a model:

• A hint of waste elimination
• Knowledgable work is perishable
• Sustainable pace
• Perfect is the enemy of good enough
• Reflect and adjust
• Craftmanship
• High trust, high social capital, high collaborative culture

28:17 Enterprise scale is the big drive of the change. Adopting a lot of Lean ideas. Roling out agile at enterprise scale requires more than just learning agile practices and principles. They require Organizational Maturity.

29:02 Kanban, Real Options, and CMMI help us there.

29:08 Lean has its own paradigms. Lean is defined in paradigms. First focus on value. Customer initmacy is vital in order to understand value. Value is contextual and context is temporal. The value of a new bottle of water to this young lady at this point in her life (in the middle of the desert) is much higher now than when the bottle is sitting in a box of 24 ready for sale. This is very important in order to optimize the profit.

30:03 The cost of late delivery is high because of the uncertainty of future value. [Geoffry Moore's graph!] Lean has a notion of cost of delay. A week late, two weeks late, a month late, two months late. Business is really bad at calculating this[???]

30:28 Lean asks us to Flow (picture of domino stones falling over).

30:33 Flow seeks to reduce cycle time through control of inventory (WIP; Work-In-Progress) (across systems) and a focus on keeping the value stream working effectively.

30:46 Flow asks us to remove impediments quickly and eliminate them in the future through root cause analysis so that it won't happen ever again (for extra bonus points).

30:50 Flow requires us to adopt a paradigm that inventory is not an asset. Inventory is a liability.

31:03 Through Value and Flow, Lean takes the view that inventory is a liability, and hence, we find an overlap with the Agile Manifesto's 4th value: Responding to change over following a plan (where requirements are a liability).

31:23 Lean also introduces the concept of Pull. Pull is a way of limiting work-in-progress. And balances this against throughput.

31:36 Pull insures that no one ever becomes overloaded.

31:45 Pull is a concept that the Agile Manifest did not capture. The closest it comes is the concept of sustainable pace from the Principles behind The Manifesto.

31:53 There is also one truly insidious behavior of Wester corporate management culture that the Agile Manifesto did not address… and that is the relentless pursuit of efficiency rooted in the Scientific Management by Frederick W. Taylor [picture of T-Fords manufactured on lopende band].

32:44 What is the most efficient way to paint a fence? [picture of wooden fence to be painted]. The key thing to understand is that in an value added activity there are also transaction costs (in this case the setup (get the right paint. brushes, sandpaper, tools, perhaps repair any damage to the fence) and cleanup (could be as simple as cleaning up your brush before going to lunch so they don't harden up, removing paint spots) that can be amortized over a greater number of value items (in this case, painted sections of fence). In short, at the beginning and end of any value activity, there are transaction costs.

33:30 And in knowledge work problems there is also a thing as communication costs like project management and progress meetings. Coordination costs can grow non-linearly with batch size. We've kown this since Brookes wrote the Mythical Man Month. That's a key difference with manufacturing—coordination costs do not grow with batch size in manufacturing. If so, make the batch size smaller.

35:20 The prevailing paradigm in Western management was that overheads (transaction and coordination costs) were inevitable and efficiency was achieved through economies of scale (i.e. large batch sizes). In some cases that makes sense in manufacturing because the coordination costs don't grow. All you need is more capital. But it doesn't work for our [knowledge] industry because the coordination costs grow non-lineairly.

35:50 However, the Japanese took a whole different approach to efficiency. If the transaction and coordination costs were too high to allow a batch of work completed economically… just make them smaller. And the reason was, they didn't have the physical space to store inventory, and they didn't have working capital to buy it in the first place. They were actually forced to come up with this approach because of constraints.

36:20 Then the simply had to find a way to reduce the overheads in order to make small batches efficient. They just had to overcome the constraints they had in the fifties that forced them down this road and turned out to be a better way to go.

36:20 Smaller batches allow us to bring the right product to market at the right time to react faster. (picture of waterrad met small scoops). That releases more business value.

36:47 Releasing more value for the business. And it avoids problems like this where a mass manufacturerer overproduces e.g. cars. [picture of inventory lot thousands of brand new cars waiting to be purchased]. Batch size problems from an economies of scale paradigm are what cause US auto manufactureres to deeply discount when the over produce the wrong model or specification.

36:55 Small batches avoid waste and make a business more responsive to the market [picture of running cheetah] [small batches -> less waste -> higher ROI].

37:06 In the style of The Manifesto we would say: Elimination of Waste is the Lean paradigm opposite of Economy of Scale.

37:12 Which might lead us to extend the agile values to include: We value elimination of waste over achieving economy of scale.

37:20 …and we value the delivery of value over reduction of cost.

37:40 Venn diagram of Lean and Agile showing that there's overlap. Value, Flow, Kaizen. Lean has a number of things that don't exist in Agile. And Agile has a number of things that don't exist in Lean.

38:06 Lean & Agile Venn diagram

• Lean & Agile
  • Knowledge Work is Persihable (inventory is a liability rather than an asset]
  • Continuous Improvement (kai zen)
• Lean
  • Eliminate Waste
  • Balance Demand against Throughput
• Agile
  • Perfect is the Enemy of Good Enough
  • High Trust, High Social Capital
  • High Collaborative Culture

38:41 Kanban is a Lean solution for Value, Flow & Pull. [3 vertical slices op previously used pictures: bald guy with roll of dollar bills on top of head; falling domino stones; strong guy pulling rope] Kanban is a major direction in terms of the future of agile. Kanban is now beings successfully introduced in to software engineering. It is gaining momentum in the community.

39:33 Some folks are calling kanban "the most innovative thing in agile for years" or "not agile at all but waterfall in disguise". Who is right? Let's take a look at that.

39:55 Kanban (or signal cards) limit work-in-progess and create a pull system. [see slide

40:33 Kanban is now established in the Agile community. E.g. Yahoo is using it extensively.

40:48 Kanban does not use time-boxed iterations. Something that some of us in our community consider sacred: a one week, two week or four week iteration, does not exist in Kanban. A religious anecdote: So, before I join your team, can you tell me how long your agile iteration is? Answer: Your question does not compute. This is going to rock the foundation of our community. No iterations? Are you kidding?

41:47 We really don't do any estimation or planning? Almost completely eliminates planning and estimation with Kanban.

42:17 Kanban rocks the foundations of agile practitioners who focus on practices rather than paradigms. Pair Programming and Standup Meetings are fine in Kanban. But Time-boxed iterations, Generalist Workforce, Burndown Charts and Planning Games are totally optional in Kanban. And I can make this list much longer.

42:35 Kanban forces us to examine what it really is to be Agile and to examine what the Agile movement is all about and to embrace change in our own practices.

42:52 If we examine Kanban against the underlying paradigms… We alread know Kanban covers the Lean ideas of Value, Flow, Pull. And has been shown to enable Continuous Improvement both in software development and manufacturing.

43:21 But what about the Agile ideas that don't appear in Lean? Does kanban embrace the notion that perfect is the enemy of good enough?

43:30 Well, yes it does! Kanban enables single-piece flow, constant incremental delivery, frequent releases of working code (every week or two weeks), transparency on WIP, and frequent prioritization of input queue. In other words, you can come up with the best solution early in the market and then keep modifying it to what people want, pursueing value.

43:56 What about a high trust culture? Yes! Kanban enables and encourages a kaizen culture of shop-floor empowerment through transparence, visual control and kanban signaling. Kanban signaling is a fantastich mechanism for self-control and self-organization because you don't need a special project manager going around telling people what to do directing the performed tasks. The visual control mechanism allows them to control all that.

44:26 Or the notion that knowledge work is perishable? Yes! Kanban is designed to optimize cycle time through exposure of waste, and through prioritization of inputs until the last responsible moment. The idea that you are visualizing the value stream and see where all the work in progress is and the things that move through it helps you visualize things and gets the whole team talking about "Gee, that's waste there, what do we do about it?" And cycle time is shortened as a result.

45:00 What about craftmanship? Yes! Kanban encourages a stop the line mentality that encourages pride of workmanship throughout the value chain. If some things go poor quality, anyone can put their hand up and say "This is not moving here". And if you've got work in progress and you've got 2 or 3 with poor quality, everything is stopped, and the team has to focus exclusively on fixing the things that are wrong or broken. A really high craft ethic.

45:42 And sustainable pace? Yes! Through its WIP limit and pull system, Kanband insures that the team is never overloaded.

46:00 Kanban meets all the criteria for a Lean and Agile method.

46:06 But isn't it just waterfall in disguise? Some of you are thinking and stating this.

46:13 Kanban embraces division of labor—isn't that waterfall? At large enterprise scale, division of labor is inevitable. It isn't practical to hire large workforces of highly skilled, top performing generalists. You can have business analists with kanban and give it over to developers. Why did thay have division of labour on these assembly lines in the first place? Well, the main reason was that they had workers there who didn't understand English. So they could train them to do get good in one thing and then gradually expand that. But there were many many jobs to be done to build a car, so they needed to have lots of division of labour. And that same principle is also true at large enterprise scale. Division of labour is inevitable because of labour pool constraints.

48:17 Nor is it economical!!! The best people in our industry are expensive. Hiring a few of them is good. Hiring a lot of them is expensive. From an economic perspective, it's better to have a number of people that have a narrower skill set for division of labor. In any value chain there must be some division of labor. Division of labor has, what economists call marginal utility. What does that mean?

48:48 For example, there is marginal utility in employing a user experience professional to design a user interface, compared with a generalist developer. UI specialists are better at it and cost about the same. Developers don't do UIs anymore like they did in the early days. Marginal utility forcing some divsion of labor.

49:27 On the other hand, Flow embraces the idea of elimination of bottlenecks and waste (transaction adn coordination costs).

49:42 And hence, Flow drives us to a more generalist workforce with fewes handoffs between specializations. A handoff is a transaction cost and produces waste. So Lean is telling us to do less of that and have a generalist workforce. These are opposing forces.

50:00 Flow pushes against the division of labor. But marginal utility, cost and other economical concerns push back. Division of labor is inevitable! So the idea to have a generalist workforce is idealist. Maybe you can grow a small company based on those ideas, but you can't do it at large enterprise scale. As a community we need to recognize that. That is, how to be agile with division of labor, rather than just saying "Division of labor is wrong! Don't have any handoffs. Only hire generalists." That makes us look like cranks. It doesn't play in big enterprise clients.

50:52 Kanban gives the Agile community a convenient way of embracing division of labor without losing our Agile values. It's an Agile and Lean method that solves the division of labor issue. And we can stop telling bad companies "Ah, forget your specialists. Just get rid of them all and get generalists."

51:22 If you embrace Lean Thinking to its fullest then a lot more wil change.

51:36 And I call this change Software Supply Chains

51:48 So what does that mean, Software Supply Chains? Is that like the end to craft-based development? And all the developers go "OMG, the end of craft-based development? Are you serious?!"

52:00 There are two key technologies that are driving this: Software Product Lines (a.k.a. Software Factories) and Cloud Services introduce re-use. Cloud Services allow one to put compute services into a web service and allow anyone to use them. And there are some very very big companies in the world that enable this kind of stuff. Web-service re-use and allow value exchange. Software Product Lines is the idea that you can describe a type of software assets, not just ?? but also deployment scripts and all sorts of things in XML and they can be paritally complete. So someone can give you 80% of something which on its own might not compile. But it's re-usable assets that you can take, refine, finish and compile. The combination of these two creates the possibility of re-use in ways that were never possible with OO technology or Aspect Oriented technology and so forth. In WXP there are 7 or 8 dictionary components. Not much re-use there because the developers could not create or derive any value from them in the value chain.

54:56 Times have changes. Technologies have changed. And now provide a means of economic value exchange between partners in a value chain. Someone can build something that is partially complete and someone else can reuse it and value can be exchanged through usage. That's really technology that is possible today and will be commonplace in w few years as a means of exchanging value.

55:21 In my mind, that means that architecture and modelling and analysis will be back in fashion within the next 3-4-5 years, but not as a means to drive for perfection in planning… And that is going to change what we value in Agile practices. If we're building cloud services that massively reuse other people's services sitting in the cloud. We can't look at their source code or refactor their source code. A lot of the practices that we hold near and dear don't work all that well in a cloud services world. So how do we build a community that embraces that kind of change rather than having a community that gets destroyed by it?

56:11 Okay. Modelling will be back in fashion and it will be doing things like enabling the separation of variability and encapsulating common behavior. A mobile phone has a whole stack of systems. It's built on a two-way radio system and is very old and changes on a 20-year time scale. The OS changes maybe every five years, less probably. On those time scales, 2 years, 5 years, 20 years, you don't need two week iterations. On the other hand, what about the UI? Everyo cell phone carrier that buys these kind of devices from the manufacturers requires that the UI be unique to them. By far the biggest labour effort is to produce these kind of devices customizing the UI and the applications. Microsoft learned that the hard way by Windows Mobile. They didn't understand the cell phone market. So, that piece of the industry needs to be very agile. If you build the devices and want to make the most profit, you should focus in customizing the UI and be very agile at that. So by separating out variability you enable a value chain to emerge.

58:20 Tools that turn diagrams in to code, or map different levels of detaul (domain specific languages) embrace the notion that perfect is the enemy of good enough. ANd the tools that allow this to happen are Domain Specific Language Tools.

58:42 So my view is that re-use will drive the next wave of Lean productivity improvements and enable the next wave of fast response development methods that power business agility. It's quite easy to get a 4x improvement with an Agile productivity team. As a manager I got appointed 20 or 100 guys. Here are 100 guys that work for you. And it's quite easy to get a 4x improvement. But what I know is that you can get a 10x improvement out of them. And it's not terribly difficult. It's achievable. If you compare how they build a Daimler Benz in 1908 with how Toyota builds a Corolla today, it shows a 200x productivity improvement. And the software productivity lines knows they can generate at least a 10x improvement through re-use. You multiply what you get out of Agile and Lean methods with what the academic guys know from software product lines, you get a hundredfold improvement in productivity. An improvement on the same kind of scale that we've seen in manufacturing over a 100 years as they moved from mass to lean manufacturing.

01:00:34 Software development will not be off-shored to craft-based development shops for labor arbitraged just for the cost optimization. That model is going away over the next 5-10 years.

01:01:01 Instead, high value, highly differentiated, high variability functionality will be built in customer intimate near/on-shore proximity centers, on-demand. The stuff that needs to be very customer intimate will be built locally in proximity centers in a very agile way. [EPICENTRA all over Holland] "I need a new UI for my cell phone with the following modifications and I need it six weeks from now. Please deal with that." And someone will do that locally where they will be with the carrier [client]. Let's pick someone, T-mobile in the US, say, ideally you put them in the same building.

01:02:02 Low value, undifferentiated commodity functionality will be built offshore in low cost centers. Doesn't mean India. Might be the Phillipines or China or Nepal or Africa. But India and China will be where the big brand name companies come from next 5, 10, 15 years.

01:02:28 Okay, moving on. Next topic: CMMI. Organizational Maturity is still relevant, even with agile methods. This is the key thing to me, with enterprise customers because what they describe to me is requirements. The say things like "David, we need to be more predictable. You know, we're doing something, making an estimate, and we need to be within 10-15% of that estimate." Predictability means low variability. "And the lead times need to be short, too, because we get paced in the market by our competition and we're nog fast enough. And we need to be much more data driven and objective and less reactive and subjectory." All the things I just said, my clients said to me, fairly high-ranking banking executives around the world, they have just described CMM level 4. Their business objectives require them to have an organziational maturity the equivalent of level 4. They don't need the appraisal, but they need the organizational maturity.

01:03:41 Achieving high maturity is essential for enterprise scale succes (with agile methods).

01:03:55 During the early stages of agile adoption in an enterprise we see core capabilities developed. Agile teams very quickly get very good at these things:

• Project Planning
• Measurement & Analysis
• Verification (automated)
• Validation (automated)
• Project Monitoring & Control
• Process Definition
• Requirements Development
• Requirements Management
• Configuration Management
• Product Integration
• Technical Solution

These are all CMM level 2 and 3 type stuff.

01:04:20 In fact, agile teams put in place most process areas to meet a low maturity CMMI Level 2 or 3 appraisal. Shows organizational maturity at a low level.

01:04:46 But we're not good at enterprise scale maturity levels. Areas that agile team can be weak in that are required at enterprise scale:

• Decision Analysis and Resolution—making objective decisions based on the ??? against criteria; in fact, most of the industry is not good at that, not just the agile practice
• Integrated Project Management—we're still struggling with it
• Training Program
• Supplier Agreement Management—we talk a lot about impediment removal be we kind of just wave our hands about it.

We're not very rigourous about these things, and t get to high maturity, we need to fix that.

01:05:31 Okay, so achieving high maturity requires a shift in culture and mindset.

01:05:38 And as a community we are capable of being clever, we learn from out mistakes and adapt and could develop our own maturity model… Or, we can choos e to be wise and learn from the experience of others Issue & Risk Management I had the arrogance 6 years ago to say CCM is bunk. Let's just invent our own maturity model. And there were some others at the conference kicking around the same ide. Well, here I am six years later confessing that I was just ignorant and arrogant and I should have known better. And over the years I have com to realize that the model that exists in CMMI does work and I see it happening in organizations. Organizations that I have led. So I take that back and I have learned from the book. Why ??? we learn from others. And I think this is a core dysfunction of our community. We are good at being clever and we exclude a lot of things from others. [NIH syndrome] And we are really not being wise. We definitely need to get better at that.

01:07:11 the Capability Maturity Model Integration exists and has 20 years of development behind it. With really some very smart people and a lot of people with a great passion for our industry. Some of them spent a lifetime, more than 40 years, of their carreer trying to figure out how to make our industry successful and how to make software that make organizations successful. They are not dummies. Smart guys that over the past years have developed relationships with some who I call friends.

01:07:58 So why is the CMMI relevant to the Agile community. A very brief history here. Lean (kaizen) is in large part based on the teachings of W. Edwards Deming and his System of Profound Knowledge.

01:08:13 So what's the scoop? But, (and this is not widely understoods), when he was asked by the government Watts Humphrey's original vision for the Capability Maturity Model…

01:08:25 …to find a way of enabling Deming's System of Profound Knowledge in the software engineering profession. He knew that Deming's way was the right answer to the waterfal industry, particular in the manufacturing industry. And he wanted to solve this problem for software engineering. Unfortunately a few things went wrong and stopped in 1991 when the airforce forced the SEI to create the levels.

01:08:51 Despite the fact that he based to maturity model on Philip Crosby's Manufacturing Maturity Model to make that happen. The Deming message got diluted and very quickly got lost.

01:09:07 So Lean allows the agile community to speak a language that is understood at the SEI. Written a 57 page paper: CMM and Agile, why not embrace both? SEI made a couple of wrong moves in articulating and positioning CMM, but we are now fixing that. Having an agile appraisal method. There is a lot of reaching out going on on the academic and software engineering institutes saying that ??? What I'm not seeing is any reaching out from our side to understand them. In fact, if you followed the review process for this conference, you will notice that some people submitted CMM and Agile papers, but every single one of them got rejected. And more than that, the rejection comments in many cases were vitriolic. They were ignorant, uninformed and vitriolic. And there are people in our community that are to be ashamed of that. Narrow-minded. We need to get over it if we are to get to solve the big enterprise scale problems.

01:10:58 So, what does High Maturity mean?

01:11:03 The Agile community has been slow to embrace objective, managed, quantitative techniques that drive for predictable results (CMMI Level 4). Predictability means a focus on reducing variability.

01:11:12 Predictability can be used to drive competitive advantage through shorter lead times. [see Hypergrowth!]

01:11:19 Predictability allows a team to be more agile—to respond to change faster. Rather than wait for something to go wrong and react to it, and make changes, if you predict something, you can [pro-actively] react earlier [== pro-act] and can stop it getting so bad. It allows you to pre-vent problems and disasters.

01:12:10 CMMI Level 4 also requires that ther is long term organizational learning. This requires recording of key decisions and a move away from reliance on tacit knowledge.

01:12:17 Without institutionalized learning, mistakes can be repeated. We are not really being clever. [Institutionalize learning by investing in Pattern or Pearl Languages and Excellence Guides]

01:12:26 The Agile community does aspire to a continuous improvement (kaizen) culture. Well, guess what, so does CMMI Level 5. That was the original goal we had in 1987. We have the same goals in mind, so we need to get over the fact that these guys made a few mistakes. If we are failure tolerant, can we accept the fact that they tried a bunch of stuff and that it didn't work well and they were smart enough to actually address that?

01:13:00 Agile teams that fail to embrace objective, quantitative management fail to mature beyond the equivalent of CMMI Level 3.

01:13:21 There is a tendency to rely on subjectivity and some degree of heroic effort to achieve results. Retrospectives tend to be very subjective, and not to be heavily data-driven. That is why with my teams I do operational reviews that are very data-driven because from the tracking systems we extract a lot of data and reports and this is documented in my books an d many other things over the years.

01:13:46 Achieving enterprise scal succes with agile methods requires that change is institutionalized. While we are on the topic of maturization, ??? has written a great paper for this conference last year that showed scientificly that CMMI Level 4 and 5 organizations adopt agile methods faster and better than low maturity organizations. That is a predictable result and it turned out to be true. So I have come to realize in my consulting practice that enterprice clients I need to focus on organizational maturity and less on productivity. And I woke up one morning and thought, OMG I'm saying things that Humphries was saying 10 years ago. And Cutters was saying 6 years ago. ANd, yes, these people have been doing this a lot longer than me and have been through the same kind of life experiences, albeit different cultures, different projects, but gradually I am learning to be wise. It has taken me 41 years, but I'm getting there.

01:15:01 This is done by adding rigor to delegation and empowerment, through firm definition of policies and authority, and through encouraging a highly empowered kaizen culture of process innovation. Enabling self-organization

01:15:19 High maturity is never achieved through imposition of positional power and acquiescence. Get it out of your mind that high maturity and agile are incompatible. HM Levels 4 & 5 are what we have been aiming for all the time.

01:15:54 Kanban is emerging as the method to achieve agility and high maturity. It is something that helps the cultural change that causes the organizational maturity to fall in to place. What you see is that the productivity improvement doesn't happen until later. ...imposing FDD on teams at companies like Sprint and Motorola and getting massive improvements: 4 times, 10 times. Fail to scale it, fail to institutionalize it, and a year later it was all gone. On time, under budget, super high quality. But didn't institutionalize it so didn't make Motorola agile.

01:17:26 Kanban creates the desired cultural shift to an objective, consensus-based, empowered kaizen culture. [better: consent-based culture].

01:17:47 So it's really emerging as a way, Kanban has enabled agile team to break through to CMMI Level 4 behaviours. I'm sure it's not the only way. But I have seen high maturity on FDD teams on enterprise scale. But I haven't seen the cultural shift I've seen with kanban.

01:18:22 real Option Theory. Options have value. Options expire. Never commit until you know why.

01:18:36 Real Options change everything. From project planning and scheduling to risk management to portfoio management and governance.

01:19:22 Real Option theory asks us to stop gazing in to our crystal ball and is going to start to make some very significant changes, for the better in my opinion.

01:19:45 Stop making plans about an uncertain future. Don't try to predict the future.

01:19:50 React and have options available and know how long it wil take to implement the option and when you need to make decisions. And what causes the option to become valid or invalid.

01:20:00 Delay as decisions as late as possible. Wow! That sounds familiar. We've heard that before in our community. Lats minute decisions.

01:20:15 Right. Wrong. Uncertainty. People prefer to be right when making a decision. But guess what, we prefer to be wrong rather than be uncertain. We'd rather make a decision today and have it be wrong than embrace uncertainty [¶ twijfel en durf te kiezen] and make the decision later. The Real Option Theory says you have to delay that decision as late as possible, so how do you overcome that uncertainty. Well, you figure out when you can make the decision. So rather than say "Okay, I'm not sure when we'll make a decision, you say, this decision can be deferred until this specific date. Things like the priositization methods in kanban enable this stuff.

01:21:21 So you gather as much information as you can before you make a decision. If you defer it as long as you can, you're able to react.

01:21:26 Have options available to reacht to events as they unravel. You frame the ways to react to as late as possible.

01:21:31 Find ways to push the decision point back as late as possible. This resonates with perfect is the enemy of good enough [¶?]. E.g. when organizing a conference in 6 months, don't have speakers come up with specifics now. Just a very general outline and market the hell out of that en have the latest, freshest on the conference itself.

01:23:17 So… What does the Agile Community need now (to prepare for and embrace these changes)?

01:23:25 The key thing in my mind is 1) A formal mechanism to embrace change in our Agile world; 2) An underlying model for agility, and an institutional home for that model; 3) An Agile Alliance program with formal meetings an publications. A few of us have come together at an unconference last year to come up with a proposal for this. Do these formal meetings regularly, like trhee times a year.

01:24:02 Provide in the documentation for this. We need to be seen to be open-minded and embracing of new ideas. We should seek to expand coverage and eliminatie more bad paradigms. That allows us to look at sumbimssions for next years conference and say "Is this agile or not?" and come up with a really objective answer to that and that allows us to embrace innovation and prevent us rejecting new ideas. Because we've been terribly terribly bad at rejecting new ideas for the last 5-6 years.

01:24:32 We need to expand coverage and eliminate more bad paradigms beyond the ones I've outlined today.

01:24:45 Linda Rising's recent work on why we have to work 8 hours a day. Why do we do that? It's an 18th century paradigm developed to run cole mines and cotton farms. Why are we still doing it in the 20th century of knowledge work? It doesn't make sens, right? Linda is going after something that's broken. And that is soemthing we should be embracing as a community. Let's figure out a bad paradigm and figure out what the right answer is and embrace that in the body of knowledge we call agile. The questions is should we work more or less? The basics are that you probably want to work in bursts of 90 minutes of high energy level. We should be tracking the value that we're bringing rather than the time we're spending.

01:25:51 Embrace management and organizational skills as essential to furthering our goals. Be open to the SEI, the scientific community and the CMMI. I find almost every single time with clients that developers are not the problem. And if they are the problem, as a manager I can fix that within 3 weeks to 4 months. And generally when you fix that, the organizations hasn't gotten any better. The reason is that the problems are elsewhere. And you deliver the real value, you unleash the potentioal of the agile community by fixing the organizational problems. Let's start embracing the idea that organizational maturity is our friend and get out there and solve the enterprise problem that we've been talking about the last couple of years.

01:27:21 Recognize that Division of Labor is essential but it doesn't mean an end to our craftmanship ethic. We saw that with kanban. An understanding that as we move to a model of software supply chains, the practices will changem but our underlying agile values can remain intact. How do we do pari modeling for software chains?

01:28:21 So if we do all this, I genuinely belief that we are going to fix this narrow-mindedness and we wil have a community that can thrive through several decades and several discontinuities in technologies and tools.

01:28:40 What's the alternative? A marginalized clique of crafstmen, building software the old fashioned way. Because, belief me, 5-10 years from now, what we believe to be best practices today to be agile, that will be old fashioned then. Do we want to at the leading edge of what's new? Or do you want some other guys telling us "Oh you guys are all doing it the old way?"

01:29:10 I like to thank you all for your time and your attention.

CMMI requires you to show evidence about maturity levels.