2 years, 9 months ago

Going Beyond Defined Agile Methods

I’ve been spending nearly half my time in Philadelphia over the past while, and I just happened to have a spare Saturday yesterday, so I hightailed it downtown. I had two objectives – to explore the Museum of Art and to attend a Brahms concert by the Philadelphia Symphony Orchestra. One of the featured exhibitions in the adjacent Perelman Building caught my eye. It’s named, Work on What You Love: Bruce Mau Rethinking Design. I wasn’t sure what to expect; I certainly hadn’t heard of Bruce Mau before, but I am always interested in design and design methods.

The gallery is essentially laid out to be controversial, to challenge one’s status quo thinking. In a video, Mau says, “practically everything that we do is being designed or redesigned; if you think about the way that we live now our life from womb to tomb is a design experience. If we want a great life experience you have to design it.” Mau goes on to say his work is focused on allowing people who aren’t designers to have access to the power of design, in their life, their work, in their business. Giving people the tools to design their future in a highly positive way.

Almost at the door of the gallery is a huge exhibit detailing his “incomplete manifesto for growth”. And the manifesto principles look like a superset of the Agile development manifesto, but writ large, with vastly greater ambition. First there are 43 principles. What! I say to myself, how can that many principles be useful? But of course once you start reading you are hooked. The Agile principles are embedded, but there’s much more. Let me give you a taster:

1. Allow events to change you. You have to  be willing to grow. Growth is different from something that happens to you. You produce it.

5. Go deep. The deeper you go the more likely you will discover something of value.

8. Drift. Allow yourself to wander aimlessly. Explore adjacencies. Lack judgment. Postpone criticism.

9. Begin anywhere. John Cage tells us that not knowing where to begin is a common form of paralysis. His advice: begin anywhere.

13. Slow down. Desynchronize from standard time frames and surprising opportunities may present themselves.

16. Collaborate. The space between people working together is filled with conflict, friction, strife, exhilaration, delight, and vast creative potential.

20. Be careful to take risks. Time is genetic. Today is the child of yesterday and the parent of tomorrow. The work you produce today will create your future.

22. Make your own tools. Hybridize your tools in order to build unique things. Even simple tools that are your own can yield entirely new avenues of exploration. Remember, tools amplify our capacities, so even a small tool can make a big difference.

29. Think with your mind. Forget technology. Creativity is not device–dependent.

31. Don’t borrow money. Once again, Frank Gehry’s advice. By maintaining financial control, we maintain creative control. It’s not exactly rocket science, but it’s surprising how hard it is to maintain this discipline, and how many have failed.

39. Coffee breaks, cab rides, green rooms. Real growth often happens outside of where we intend it to, in the interstitial spaces—what Dr. Seuss calls “the waiting place.”

41. Laugh. People visiting the studio often comment on how much we laugh. Since I’ve become aware of this, I use it as a barometer of how comfortably we are expressing ourselves.

These are just a sample. You get the idea. This is Agile for the real world. For those people that are stuck in the zone of religious adherence to Agile development methods this may be anathema. But it’s a wakeup call. Invent your own.

The complete list and much more . . .

Work on What You Love: Bruce Mau Rethinking Design
November 21, 2015 – April 3, 2016

AFTERWORD: I wonder to what extent these principles map to a variety of design disciplines? In fact surely all design disciplines are creative processes. Would this include musical composition? I see no reason why not.

2 years, 9 months ago

Going Beyond Defined Agile Methods

I’ve been spending nearly half my time in Philadelphia over the past while, and I just happened to have a spare Saturday yesterday, so I hightailed it downtown. I had two objectives – to explore the Museum of Art and to attend a Brahms concert by the Philadelphia Symphony Orchestra. One of the featured exhibitions in the adjacent Perelman Building caught my eye. It’s named, Work on What You Love: Bruce Mau Rethinking Design. I wasn’t sure what to expect; I certainly hadn’t heard of Bruce Mau before, but I am always interested in design and design methods.

The gallery is essentially laid out to be controversial, to challenge one’s status quo thinking. In a video, Mau says, “practically everything that we do is being designed or redesigned; if you think about the way that we live now our life from womb to tomb is a design experience. If we want a great life experience you have to design it.” Mau goes on to say his work is focused on allowing people who aren’t designers to have access to the power of design, in their life, their work, in their business. Giving people the tools to design their future in a highly positive way.

Almost at the door of the gallery is a huge exhibit detailing his “incomplete manifesto for growth”. And the manifesto principles look like a superset of the Agile development manifesto, but writ large, with vastly greater ambition. First there are 43 principles. What! I say to myself, how can that many principles be useful? But of course once you start reading you are hooked. The Agile principles are embedded, but there’s much more. Let me give you a taster:

1. Allow events to change you. You have to  be willing to grow. Growth is different from something that happens to you. You produce it.

5. Go deep. The deeper you go the more likely you will discover something of value.

8. Drift. Allow yourself to wander aimlessly. Explore adjacencies. Lack judgment. Postpone criticism.

9. Begin anywhere. John Cage tells us that not knowing where to begin is a common form of paralysis. His advice: begin anywhere.

13. Slow down. Desynchronize from standard time frames and surprising opportunities may present themselves.

16. Collaborate. The space between people working together is filled with conflict, friction, strife, exhilaration, delight, and vast creative potential.

20. Be careful to take risks. Time is genetic. Today is the child of yesterday and the parent of tomorrow. The work you produce today will create your future.

22. Make your own tools. Hybridize your tools in order to build unique things. Even simple tools that are your own can yield entirely new avenues of exploration. Remember, tools amplify our capacities, so even a small tool can make a big difference.

29. Think with your mind. Forget technology. Creativity is not device–dependent.

31. Don’t borrow money. Once again, Frank Gehry’s advice. By maintaining financial control, we maintain creative control. It’s not exactly rocket science, but it’s surprising how hard it is to maintain this discipline, and how many have failed.

39. Coffee breaks, cab rides, green rooms. Real growth often happens outside of where we intend it to, in the interstitial spaces—what Dr. Seuss calls “the waiting place.”

41. Laugh. People visiting the studio often comment on how much we laugh. Since I’ve become aware of this, I use it as a barometer of how comfortably we are expressing ourselves.

These are just a sample. You get the idea. This is Agile for the real world. For those people that are stuck in the zone of religious adherence to Agile development methods this may be anathema. But it’s a wakeup call. Invent your own.

The complete list and much more . . .

Work on What You Love: Bruce Mau Rethinking Design
November 21, 2015 – April 3, 2016

AFTERWORD: I wonder to what extent these principles map to a variety of design disciplines? In fact surely all design disciplines are creative processes. Would this include musical composition? I see no reason why not.

4 years, 7 months ago

Agile is not Dead, it’s Morphing

I note healthy discussion around whether Agile is Dead [ref 1]. And while I may sympathize (sic) with many of the comments, particularly the commercial trivialization of education, the core issue must surely be the difficulty of adopting de facto Agile practices to support real world enterprise programs and projects. My experience is most of the advice and guidance out there is predicated on scaling the de facto Agile development methods. And this isn’t the best place to start.

An exception is Dean Leffingwell’s SAFe, [ref 2] which does introduce the idea of portfolio, program and project perspectives and intentional architecture. I recommend this framework as an intelligent set of practices, but for me it doesn’t go far enough because it is still primarily about development practices. This is the core problem – that Agile is development specific and practices only. In the enterprise, Agile development needs to be an integral part of a bigger ecosystem spanning business design, architecture, requirements, modernization and operational transformation practices plus architecture, delivery and modernization disciplines.

I am indebted to Dave Thomas whose recent blog, [ref 1] includes a worthy successor to the Agile Manifesto, reducing the original, development specific values and principles to a minimalist, more generic set. He says; “here is how to do something in an agile fashion
Find out where you are
Take a small step towards your goal
Adjust your understanding based on what you learned
Repeat
And this is more useful in the enterprise context because it is relevant to a broader set of activities than purely software development.

The diagram below is an outline maturity model template for Agile in the enterprise. It suggests there are four key views that need to be part of the transformation.  In addition to agile practices we need to be equally focused on what elements of agile architecture are required for an enterprise. What the agile delivery framework is and how the existing application portfolio will be modernized to progressively eliminate the duplication and complexity present in every enterprise on the planet.

People & Process. Much of the dissatisfaction with Agile arises from the limitations of the basic Agile practices, and the need to compromise these in an enterprise context. Both DAD and RUP (yes it’s an iterative method) are examples of extended or hybrid practices that introduce coordination, phasing and other disciplines that are more acceptable in enterprises that require traceability, governance and compliance with pre-existing life cycle practices. Enterprise frameworks such as Leffingwell’s SAFe as discussed and Everware-CBDI’s SOAM are examples of frameworks that adhere more closely to the purity of Agile principles while addressing enterprise specific needs. SAFe provides a framework which is more strongly Lean, coordinating portfolio, program and project activity to meet agile release train demand. SOAM provides a complementary, full life cycle process framework for software service modernization and delivery.

Agile Architecture. There is a requirement to articulate the enterprise requirements for agility as a reference architecture for business agility. In today’s fast moving world core architecture for the business, services, implementations, technology and deployments needs to be:
under continuous development using Agile principles
derived from the assessment of business needs for response to change, and constantly updated to reflect competitive and technology opportunities and threats.
mapped to service architectures, patterns, policies and modernization strategies
modeled using MDA/MDD to allow delivery as consistent architecture runways for portfolio and demand management, programs and projects.

Agile Delivery Framework. Most enterprises have a well-defined delivery framework of tools, repositories, templates etc that are designed to support well established QA and delivery policies. This is one of the most common inhibitors that Agile projects in the enterprise have to  overcome. In an enterprise Agile context that framework must be realigned to provide maximum automation of life cycle management and governance so that key enterprise requirements for integrity can be met without loss of productivity. Similarly the development  activity must be structured so that developers can extend the architecture runway with business solution specific rules and behaviors in a managed fashion which preserves the integrity of the architecture. Everware-CBDI has pioneered this runway extension capability implemented as a model driven (MDA/MDD) capability in which the runway code is generated and provided to developers enabling very significant productivity gains in both forward engineering and even more so in iteration.

Agile Modernization.  Finally in an enterprise context the elephant in the room is the existing or legacy portfolio. Unless this elephant is addressed, the enterprise will continue to create more and more complexity, increase costs and reduce response times to change. What’s required is a discipline of continuous, Agile modernization. That means, using Dave Thomas’s minimalist manifesto [above] every portfolio item, program and project must include steps to find out the current situation and address minimum goals that reduce complexity and support a progressive modernization strategy. Without that, all enterprise Agile projects will remain narrow focus and simply add technical debt.

I suggest that while Agile is not dead in the enterprise it is certainly struggling to survive. This is because Agile practices alone will be suffocated at birth by enterprise realities of consistency and integrity; or turned into narrow focus, standalone projects; or morphed into BAU. I really don’t want to enter into a debate about nouns or verbs, life is too short.  IMO Agile has considerable momentum and it can be morphed into a ground breaking concept that delivers enterprise business agility.

References
1 Agile is Dead (Long Live Agility)
2 Dean Leffingwell SAFe

4 years, 7 months ago

Agile is not Dead, it’s Morphing

I note healthy discussion around whether Agile is Dead [ref 1]. And while I may sympathize (sic) with many of the comments, particularly the commercial trivialization of education, the core issue must surely be the difficulty of adopting de facto Agile practices to support real world enterprise programs and projects. My experience is most of the advice and guidance out there is predicated on scaling the de facto Agile development methods. And this isn’t the best place to start.

An exception is Dean Leffingwell’s SAFe, [ref 2] which does introduce the idea of portfolio, program and project perspectives and intentional architecture. I recommend this framework as an intelligent set of practices, but for me it doesn’t go far enough because it is still primarily about development practices. This is the core problem – that Agile is development specific and practices only. In the enterprise, Agile development needs to be an integral part of a bigger ecosystem spanning business design, architecture, requirements, modernization and operational transformation practices plus architecture, delivery and modernization disciplines.

I am indebted to Dave Thomas whose recent blog, [ref 1] includes a worthy successor to the Agile Manifesto, reducing the original, development specific values and principles to a minimalist, more generic set. He says; “here is how to do something in an agile fashion
Find out where you are
Take a small step towards your goal
Adjust your understanding based on what you learned
Repeat
And this is more useful in the enterprise context because it is relevant to a broader set of activities than purely software development.

The diagram below is an outline maturity model template for Agile in the enterprise. It suggests there are four key views that need to be part of the transformation.  In addition to agile practices we need to be equally focused on what elements of agile architecture are required for an enterprise. What the agile delivery framework is and how the existing application portfolio will be modernized to progressively eliminate the duplication and complexity present in every enterprise on the planet.

People & Process. Much of the dissatisfaction with Agile arises from the limitations of the basic Agile practices, and the need to compromise these in an enterprise context. Both DAD and RUP (yes it’s an iterative method) are examples of extended or hybrid practices that introduce coordination, phasing and other disciplines that are more acceptable in enterprises that require traceability, governance and compliance with pre-existing life cycle practices. Enterprise frameworks such as Leffingwell’s SAFe as discussed and Everware-CBDI’s SOAM are examples of frameworks that adhere more closely to the purity of Agile principles while addressing enterprise specific needs. SAFe provides a framework which is more strongly Lean, coordinating portfolio, program and project activity to meet agile release train demand. SOAM provides a complementary, full life cycle process framework for software service modernization and delivery.

Agile Architecture. There is a requirement to articulate the enterprise requirements for agility as a reference architecture for business agility. In today’s fast moving world core architecture for the business, services, implementations, technology and deployments needs to be:
under continuous development using Agile principles
derived from the assessment of business needs for response to change, and constantly updated to reflect competitive and technology opportunities and threats.
mapped to service architectures, patterns, policies and modernization strategies
modeled using MDA/MDD to allow delivery as consistent architecture runways for portfolio and demand management, programs and projects.

Agile Delivery Framework. Most enterprises have a well-defined delivery framework of tools, repositories, templates etc that are designed to support well established QA and delivery policies. This is one of the most common inhibitors that Agile projects in the enterprise have to  overcome. In an enterprise Agile context that framework must be realigned to provide maximum automation of life cycle management and governance so that key enterprise requirements for integrity can be met without loss of productivity. Similarly the development  activity must be structured so that developers can extend the architecture runway with business solution specific rules and behaviors in a managed fashion which preserves the integrity of the architecture. Everware-CBDI has pioneered this runway extension capability implemented as a model driven (MDA/MDD) capability in which the runway code is generated and provided to developers enabling very significant productivity gains in both forward engineering and even more so in iteration.

Agile Modernization.  Finally in an enterprise context the elephant in the room is the existing or legacy portfolio. Unless this elephant is addressed, the enterprise will continue to create more and more complexity, increase costs and reduce response times to change. What’s required is a discipline of continuous, Agile modernization. That means, using Dave Thomas’s minimalist manifesto [above] every portfolio item, program and project must include steps to find out the current situation and address minimum goals that reduce complexity and support a progressive modernization strategy. Without that, all enterprise Agile projects will remain narrow focus and simply add technical debt.

I suggest that while Agile is not dead in the enterprise it is certainly struggling to survive. This is because Agile practices alone will be suffocated at birth by enterprise realities of consistency and integrity; or turned into narrow focus, standalone projects; or morphed into BAU. I really don’t want to enter into a debate about nouns or verbs, life is too short.  IMO Agile has considerable momentum and it can be morphed into a ground breaking concept that delivers enterprise business agility.

References
1 Agile is Dead (Long Live Agility)
2 Dean Leffingwell SAFe

6 years, 30 days ago

Agile Manifesto for the Enterprise

The Agile Manifesto is rightly held in high regard, but most practitioners understand it was a response to the prevailing environment in 2001. In fact I note Scott Ambler attempted a rework of the manifesto in 2010. Specifically Scott replaced software with solution; customers with stakeholders. And in context with the Principles behind the Manifesto, he suggested improvement of the overall IT ecosystem be taken into consideration and that Agile can benefit from the Lean Principles.  

But many organizations are finding it hard to scale Agile in the enterprise and much of this difficulty is because of the adherence to specific Agile guidance. In developing the Agile Enterprise Workshop (more on this very soon) I feel it’s imperative to have clarity of how we interpret the Manifesto. So I am using Scott’s work as a basis for addressing key enterprise issues as follows:

Individuals and interactions with lean processes and tools
Working services and solutions with essential documentation

Stakeholder collaboration with agile contracts

Responding to change is intrinsic to the plan

Delivered agile architecturewhich reuses and evolves enterprise frameworksand patterns

I’m afraid this renders redundant the preference for the value of items on the left over items on the right.  In addition the introduction of architecture, whilst it may be highly controversial, is essential at enterprise level, where the level of inter-dependency is so high, and the cost of delivering yet more legacy is unacceptable. Strangely the preference of left over right might actually be reasonably applied to the architecture point.

As Scott rightly said, “We’re agile – things evolve, including manifestos”

All comments appreciated!