Friday, December 28, 2018

The need for Ad hoc, Autonomous Business Entities for Disruptive Innovation

One of the lessons of the disruptive innovation research is that when a business requires a new business model, i.e. new processes, new resources and new values, it must be lodged in an ad-hoc, autonomous entity. Building the disruptive venture within the same organization will simply lead to the same result as Nokia: it will fail, swallowed by the power of the existing model, and it won't be for lack of trying. Millions, if not billions of dollars will add to form, but won't deliver actual goods.


Cargo cult start-ups and cargo cult agility...

Adding a foosball in your lobby won't make you a startup company anymore than building wooden planes recreated the flow of American goods in Guinea sixty years ago. - Silberzahn

Cargo Cult

A superstitious belief that practicing rituals or adopting certain practices will bring in the desired results. Often used in the context of Agile and Digitalization. Companies keen on seeing the lofty goals of agility and ditalization, mimic the practices (Hiring thousands of software programmers doesn't make you a software company -- example Nokia, which failed to make the transition from hardware to software; another example is hiring tens of Agile consultants, Coaches and practicing Agile rituals hoping to reimagine a new world of rapid feedback and value delivery!) 

"Soon after WWII, anthropologists in New Guinea noticed an unusual phenomenon: tribes deep in the interior of the country were building full-sized ritual airfields and airplanes out of bamboo, grass, etc. 

Anthropologists soon discovered that withdrawal of military forces had created a scarcity of modern technological goods, and the tribes, under the influence of so-called “Cargo Cult prophets”, were converting communities’ desires for these possessions into the external forms that had brought them in the past. 

The hope that these prophets shared with their followers was that if the correct external forms were present, the actual goods associated with them would arrive." - Forbes.

Wednesday, December 26, 2018


Effectuation is the the processes of opportunity identification and new venture creation...

Transformation - distinguishing between strategy and execution

  • One of the worst mistakes of transformation is distinguishing between strategy and execution.
  • Strategy is designed by the executive management in collaboration with premier consulting firm, and Execution is delegated to second-rung consulting firm, as an after thought.
  •  The strategy thus is a romantic and mechanistic conception. 
  • It soon turns out to be - "Our transformation strategy is perfectly clear, but we had a big execution problem",
  • This leads to stalling of transformations in large companies and causes a strong push from the top management and strong tensions within the middle management.
  • The strategy is not executed because it is not a true reflection of the capabilities of the organization. 
  • If strategy execution is a problem, then execution is a strategic issue that strategic thinking has wrongfully ignored.
  • To distinguish Strategy from Execution is to exempt top management of any responsibility in the transformation. 
Courtesy: Philippe Silberzahneng

Entrepreneurial Posture

  • Employees are bombarded with messages praising the entrepreneurial posture. Innovate! Get started! Be brave! Accept to make mistakes! Be like Google! Take the plunge! There are 3 problems associated with this:
    • This is a bad prescription, since hoping for everyone to become an entrepreneur is a fantasy.
    •  It is counterproductive. Creative Chaos is not conducive to activity at all levels. 
    • The entrepreneurial imperative is stressful and humiliating. Employees are already overworked and immersed in everyday problems, under pressure for results. Not everybody can be a superhero.
  • Entrepreneurial mindset is indeed helpful, to put organization back in motion. 
  • There is a need to abandon the super-hero connotations associated with Entrepreneurship. Entrepreneurs are ordinary mortals, with a deep affinity towards partnership, collaboration to do new and useful things.
Courtesy: Philippe Silberzahneng

Disruption and Speed of Change

  • Disruption develops in a non-linear way -- first almost invisibly for years
  • Then it suddenly, after it has reached a tipping point, begins to be "noticed"
  • Incumbents' initial reaction -- is "Why Worry"?
  • But when it suddenly accelerates, sets a panic in the incumbents.
A disruption is therefore a process, not an event. It emerges and develops, sometimes for years, without any noticeable impact, at least from the point of view of the incumbents, who thus tend to dismiss it. As time passes without visible impact, the dismissal seems more and more justified when, after sometimes a long while, it goes into accelerated mode. And then it generates shock and surprise, but this shock and this surprise are entirely self-inflicted. They result from the inability from incumbents to appreciate the true non-linear nature of the disruption.

Courtesy: Philippe Silberzahneng

Tuesday, December 25, 2018

Why Organizational Change is Difficult...

Adapted from Phillipe Silberzahneng's write up.

"When an organization’s capabilities reside in its resources (initial stage of startup), change is easy: the founders decide to change, and the organization can pivot. It is the strength of startups to change very easily when the founders are aware of the need to change their model. But when, at a later stage, an organization’s abilities reside in its processes, and even more so when they reside in its values, change becomes extremely difficult."

Changing values is difficult -- for e.g. most of us don't exercise regularly or eat balanced diet despite knowing its benefits. It's a deep change in lifestyle that affect the present commitments. It's the same for companies affected by disruption.

Changing values of an organization is titanic because it entails undermining the legacy long before it allows the birth of new one.

A solution to this is create an Autonomous Entity that takes care of this disruption.

Adherence to Reality - The Management Challenge

The relationship to the world is the combination of two things: the attitude to the world and the experience of the world. The attitude to the world is the result of our mental models. It is the way we see the world, the reality, with our assumptions, our beliefs and our values. The experience of the world is about how we act in the world, how we change reality. It is based on our principles of action. Attitude to the world and experience to the world are naturally closely linked.

Monday, December 24, 2018

Nokia failed successful transition to software

Nokia dominated the world of electronic mobile but failed to make a successful transition to software. 

Sustaining and Disruptive Technologies

Courtesy: MIT

Sustaining technologies are technologies that improve product performance (technologies that help improve a product that has a well established market). Most companies are familiar with this. Companies have problems with Disruptive Technologies. 

Disruptive technologies are "innovations that result in worse product performance, at least in the near term." They are generally "cheaper, simpler, smaller, and, frequently, more convenient to use." Disruptive technologies occur less frequently, but when they do, they can cause the failure of highly successful companies who are only prepared for sustaining technologies.

As the above graph shows, disruptive technologies cause problems because they do not initially satisfy the demands of even the high end of the market.  Because of that, large companies choose to overlook disruptive technologies until they become more attractive profit-wise.  Disruptive technologies, however, eventually surpass sustaining technologies in satisfying market demand with lower costs.  When this happens, large companies who did not invest in the disruptive technology sooner are left behind.  This, according to Christensen, is the "Innovator's Dilemma."

Large companies have certain barriers to innovation which make it difficult to invest in disruptive technologies early on. Being industry veterans means that they have set ways in approaching new technologies.  Baggage from precedents (such as equipment, training, procedures) hinder a quick response to disruptive technologies.  Large companies also have an established customer base whom they must be accountable to.  These customers often ask for better versions of current products rather than completely new technologies.  Customers are a substantial barrier to innovation.  Finally, companies make decisions according to their place in the value network--or, to put it simply, companies make decisions according to where they are in the market.

YAGNI - You Ain't Gonna Need It (Now)

  • XP Practice
  • If you need a software capability in FUTURE, you SHOULD NOT built it right now because – You Ain’t Gonna Need It NOW.
  • YAGNI means practice Simple Design

The real problem with Agile

The real problem with Agile is when frequent references to the Manifesto and fanaticism surrounding it isn't too different from religious fanaticism -- a generation venerating maniacally on written scriptures that are considered immutable.

Disruptive Innovation Explained

Agile is not the solution for lack of innovation...

Some very interesting thoughts (in the context of innovation)...

  1. agility is required, but "Agile is not a miracle solution to lack of innovation."  
  2. Individual awareness of disruption doesn't readily translate to organizational awareness at a sr. mgt.
  3. Adaptation takes time.
  4. There is an inherent dichotomy in economies of scale and agility.
  5. "agility works in risk situation where possibilities are small and known beforehand; but not in uncertainty where no. of possibilities are infinite.
  6. "agility is a form of passivity with respect to its environment".
  7. Innovation is not adaptation to the environment, but to transform it.
  8. The advantage of Startups is not agility, rather it is that they don't have a legacy to protect (Innovator's Dilemma)

Sunday, December 23, 2018

Agile Disruption

Courtesy: Russ Fletcher, Slideshare

Excerpts from Innovator's Dilemma

Sears Roebuck
  • Sears Roebuck -- retailer in the US and rest of the world
  • 1880s thru early 1990s
  • Started off as Catalog of Watches and Jewelry
  • IPO in 1906. By 19060s it was the largest retailer in the world.
  • Started off selling single product category
  • The retail sector was overpriced. Sears started selling anything and everything. You could order from comfort of your home (like we do from Amazon).
  • Pioneered several innovations critical to retailing -- supply chain management, store brands, catalog retailing, and credit card sales.
  • As of 2016 its main competitors were: Walmart, Target, Kohl's, J.C. Penny, Macy's, Home Depot, Lowe's, Best Buy, and Amazon.
  • 1984 together with IBM created Prodigy - a pre-Web online web portal. Built on a private network; was distinct from Internet.
  • Simplified structure in 1992; discontinued catalog in 1993, sold Prodigy in 1996; 1999 back to retailing roots.
  • Filed for Chapter 11 Bankruptcy on 15th Oct 2018.
  • 46 Unprofitable stores were to be closed by Nov 2018.
  • It will begin closing additional 142 stores end of year
  • It missed the advent of discount retailing / mass merchandiser (e.g. Aldi, Lidl, BigW, KMart, Target, Costco, Daiso, Matalan (Bradley stoke), Home Bargains (Bradley stoke),  -- offer wide assortments of goods with focus on price rather than on service) and home centers (Large hardware store selling tools, building materials, and other household items )
  • Sears allowed arrogance to blind itself to the changes taking place in American marketplace
  • Couldn't compete with Catalog Stores ( e.g. Argos UK)
Other Leadership failures
  • IBM dominated the Mainframe market but missed by many years the emergence of mini computers.
  • Digital Equipment Corporation (DEC)
  • Xerox long dominated the Plan-paper Photocopiers business and yet missed the huge growth and profit opportunity for small talbletop photocopiers

In both DEC and Sears' case, the decisions that led to their decline were made at the time they were widely regarded as being astutely managed firms; and being among the best companies in the world.

Saturday, December 22, 2018

Resume Driven Development - RDD

RDD is the practice of the developers sliding their own features to try out the latest trend and hip technology. 

Thursday, December 20, 2018

Situational Leadership...

  • Agile project management is more about leading a team than managing a team (Cohn).
  • Understand what the team needs in terms of leadership.
  • Servant Leadership is more about Leadership than being the doormat of your team.
  • Agile leadership is situational (depending on the set of circumstances).
  • Agile works because the team is empowered - a lot of responsibility is delegated to the team (Mackenzie).
  • Situational leadership is recognizing that there is no right way of leading a team, but effectively bounce between the following styles:
    • Directing: Tell the team what to do
    • Coaching: Sell an idea so the team will do
    • Supporting: Work along with team to do
    • Delegating: Delegate to team to do
Map the above with Tuckman's phases of team development - Forming, Storming, Norming, Performing, and Adjourning. You may start with a Directing approach as the team forms, and gradually as the team matures, coach, support and finally delegate.

Agile works the best when the team is in the "Delegating" Mode.

Agile Transformation Steps

It is very important to choose the right candidate projects for Agile Transformation. Too often you will lose credibility of the right projects are not picked up. There will be stiff resistance from teams if they don't see the value of transformation soon enough.

Co existence of old ways of working is another key factor. Ensure the new ways of working are comprehensively implemented. Most often allowing old framework to co-exist will undermine the efforts of agile ways / new ways of working. This may include the traditional documentation, phase reviews and documentation sign offs.

Wednesday, December 19, 2018

Key Agile Topics

Scrum Master

1.The purpose of top level scrum ceremonies
2.The value of observed practices during ceremonies
3.Resolve impediments external to the team
4.Write deliverable, vertically-sliced stories
5.“Turn up the good” through frequent retrospectives
6.Make work visible
7.Promote a psychologically-safe team environment
8.Model servant leadership behaviors

Product Ownership

1.Product Manager / Analyst Role Evolution
2.Product Ownership
3.Customer Experience
4. NFR Overview
5. NFR Considerations
6.The Backlog
7.Value / Return on Investment
8.Technical Debt
9.Market Analysis
10.Product Design
11.Product Marketing Basics
12.Business Value Domain
13.Embedded End User Feedback

Agile Leadership

1. Team composition
2. Product ownership
3. Portfolio management / work intake
4. Customer experience
5. IaaS
6. Legacy system evolution
7. NFR and considerations
8. Talent management
9. Vendor management
10. Financial management
11.Dependency Elimination

Friday, December 14, 2018

The Coaching Habit - Michael Bungay Stanier - Tips

Questions Coaches should be asking

1. And what else?

Have you thought of
What about
Did you consider

Stop offering advice with a question mark attached.

2. What is the real challenge for you here?

Focus on the real problem, not the first problem

3. Stick to questions starting with WHAT -- 

DONT ASK WHY questions -- it will put the respondents in the defensive / OR it will appear or you indeed are solving the problem.

Example conversation

Whats on your mind?

Is there anything else on your mind?

So, what's the real challenge for you here?

And What else (in most cases the person will still have something more to add).

Probe further by asking Is there anything else?

4. What do you want?

Untangle / differentiate the NEEDS from the WANTS

5. How can i help?

6. If you are saying yes to this, what are you saying no to?

note: acknowledge the answers you get. This will encourage the speaker.

7. What was most useful to you?

Thursday, November 22, 2018

Socratic Questioning

Courtesy: Intel Teach Program

The Socratic approach to questioning is based on the practice of disciplined, thoughtful dialogue. Socrates, the early Greek philosopher/teacher, believed that disciplined practice of thoughtful questioning enabled the student to examine ideas logically and to determine the validity of those ideas. In this technique, the teacher professes ignorance of the topic in order to engage in dialogue with the students. With this “acting dumb,” the student develops the fullest possible knowledge about the topic. 

It is said Socratic Questions induce “critical thinking”.

A good Socratic question is open-ended with more than one "right" answer. It is designed to get the student to think. Take book learning and apply it to real life problems. Evaluate an idea against the student's own experiences, thoughts and logic. Students should compare, synthesize and evaluate their own ideas. They should form rules, principles, models and concepts based upon an introspective analysis of their own thoughts. Project and speculate about casualty. Predict future problems and other implications. Search for eternal knowledge, learned generalizations and universal definitions. 

Socratic questions rarely evoke factual information. The intent is to bring information, which has already been processed into the student's awareness and helps them evaluate it. Avoid questions that have a correct answer. Your questions should promote imagination, creativity and divergent thought. If a student answers, "I don't know," rephrase the question or provide an example. Repeating the question or dropping the question does not facilitate learning. 

Good questions are the core of effective teaching. They are the essence of good teaching. Lecture features teacher domination. Socratic discussion involves students as equal participants. 

Socratic questions challenge the students to think critically about their own behavior and beliefs. Socratic questions should recognize and revere the limits of human knowledge. Questioning helps students understand basic ideas and values. This will assist them in making the wisest possible choices about the conduct of their lives.  

Socrates went to actual people with strong opinions and examined them carefully about what they thought they knew. The unexamined life is not worth living. Begin class by having each student state their point of view in writing. This gives them a vested interest in the topic. 

“Socratic questioning is at the heart of critical thinking and a number of homework problems draw from R.W. Paul's six types of Socratic questions:”

1. Questions for clarification:     
Why do you say that?
How does this relate to our discussion?
"Are you going to include diffusion in your mole balance equations?"

2. Questions that probe assumptions:    
What could we assume instead?
How can you verify or disapprove that assumption?
"Why are neglecting radial diffusion and including only axial diffusion?"

3. Questions that probe reasons and evidence:
What would be an example?
What is....analogous to?
What do you think causes to happen...? Why:?
"Do you think that diffusion is responsible for the lower conversion?"

4. Questions about Viewpoints and Perspectives:
What would be an alternative?
What is another way to look at it?
Would you explain why it is necessary or beneficial, and who benefits?
Why is the best?
What are the strengths and weaknesses of...?
How are...and ...similar?
What is a counterargument for...?
"With all the bends in the pipe, from an industrial/practical standpoint, do you think diffusion will affect the conversion?"

5. Questions that probe implications and consequences:
What generalizations can you make?
What are the consequences of that assumption?
What are you implying?
How does...affect...?
How does...tie in with what we learned before?
"How would our results be affected if neglected diffusion?"

6. Questions about the question:
What was the point of this question?
Why do you think I asked this question?
What does...mean?
How does...apply to everyday life?
"Why do you think diffusion is important?" 

Starting point is this.

To understand the Element of Thought -- what it is that the speaker is trying to convery.

Three Types:

1. Spontaneous
2. Exploratory
3. Focused

Tuesday, November 20, 2018

Commitment based Management

Organizations can choose to manage by power (command and control), by process or by promise (commitments). While there is a place for each of these approaches, the first two may actually impede innovation and engagement. The alternative is commitment-based management. 

Donald Sull,
Professor of Management Practice in Strategic and International Management
Faculty Director of Executive Education, London Business School

Thursday, November 01, 2018

Sprint Retrospectives

Gems from Fifth Dimension

The Myth of Management Team

Most managers find collective inquiry inherently threatening. School trains us never to admit that we do not know the answer, and most corporations reinforce that lesson by rewarding the people who excel in advocating their views, not inquiring into complex issues. (When was the last time someone was rewarded in your organization for raising difficult questions about the company's current policies rather than solving urgent problems?) Even if we feel uncertain or ignorant, we learn to protect ourselves from the pain of appearing uncertain or ignorant. That very process blocks out any new understandings which might threaten us. The consequence is what Argyris calls "skilled incompetence"—teams full of people who are incredibly proficient at keeping themselves from learning.
Delusion of learning from Experience

We learn best from experience but we never directly experience the consequences of many of our most important decisions. The most critical decisions made in organizations have system-wide consequences that stretch over years or decades.

When our actions have consequences beyond our learning horizon, it becomes impossible to learn from direct experience.

Laws of fifth Discipline

  • Today's problems come from yesterday's solution
  • Solutions that merely shift problems from one part of a system to another often go undetected because, those who "solved" the first problem are different from those who inherit the new problem
  • The harder you push, the harder the system pushes back
  • Behavior grows better before it grows worse
  • The cure can be worse than the disease

Pushing harder and harder on familiar solutions, while fundamental problems persist or worsen, is a reliable indicator of non-systemic thinking—what we often call the "what we need here is a bigger hammer" syndrome.

We learn to live with uncertainty, because no matter how smart or successful you are, a fundamental uncertainty will always be present in your life. 

Cure can be worse than the disease: Sometimes the easy or familiar solution is not only ineffective; sometimes it is addictive and dangerous. Alcoholism, for instance, may start as simple social drinking—a solution to the problem of low self-esteem or work-related stress. Gradually, the cure becomes worse than the disease; among its other problems it makes self-esteem and stress even worse than they were to begin with.

Delusion of Learning - Peter Senge

Tuesday, October 23, 2018

Sanjay Kumar on Linkedin

Adopting #Scrum is NOT the primary goal, nor is adopting #Kanban or #SAFe. Not even #Agile.

The primary goal is to generate #better business outcomes in a predictable and sustainable manner, followed closely by creating a work environment that motivates people towards excellence and helps them grow professionally.

Agile (and the chosen process) is the enabler for these goals, not the goal in itself. In other words,#Process must subordinate to #Outcomes, not the other way around.

If it does not, feel free to switch, customize or evolve your current process. If you do not, your agility may be severely limited... DOES NOT matter what fancy name you call it.

Monday, October 22, 2018

Agile Transformation Woes

  1. Inadequate or poorly defined reference.
  2. Poorly designed training program.
  3. Disconnect between old and new models.
  4. Inability to choose the right candidate projects.
  5. Forcing agile to initiatives that could go waterfall.
  6. Ignoring the business, vendor and support teams as part of the transformation.
  7. Not providing a career path for Project Managers, Business Analysts, Software Testers or leaving it to the judgement of individual teams.
  8. Management using agile to drive their own agenda.
  9. Management using agile metrics to compare and drive teams.

The impact of inadequate and dysfunctional training on Agile transformation process: A Grounded Theory study


This research discovered that inadequate and dysfunctional training was one of the critical issues that affected Agile transformation process. This study shows that comprehensive and functional training is not often provided to support Agile transformation. This paper shows the primary causes of inadequate and dysfunctional training, its adverse consequences on the transformation process, and the heuristic and ad-hoc treatments as the strategies used by Agile teams to cope with this challenge.

Comprehensive training is important in Agile transformation process. Inadequate and dysfunctional training causes several challenges and problems for software companies and development teams when moving to Agile. Several ad-hoc strategies identified by this study can be employed to help software teams and companies facing similar problems.

[Most recent experience proves this...]
Sprint Retrospective Anti patterns

1. There is no Retro
2. Retro is cancelled or postponed
3. Rushed retrospective
4. What should remain within the room during discussions goes out
5. Team members whine instead of constructive discussion. These contribute to the bias that agile is not working
6. Team does not check for items from previous retro.
7. PO absent for retrospectives
8. Not all team members participate.
9. No minutes / notes during retro
10. Retros are endless cycles of blame, fingerpointing, failure
11. Bullying
12. Stakeholders participate in retros (they aren't supposed to).
13. No adequate space; rooms booked adhoc
14. Line managers participate
15. Someone outside team requests for peek into retros.

Wednesday, October 17, 2018

Is your team really a team?


It’s crucial to pay attention to whether or not a working group is a team because it dictates what kind of structures to build and how to support the team. We see organizations spend tremendous amounts of energy in trying to coach Temporary Alliances and Pseudo-Teams as if they were teams, when in fact the kind of support those working groups needs is very different from what a team needs.

Thursday, October 04, 2018

Epics, Capabilities, Features, Stories (Another View)       Epics

Epics are parcels of work large enough to require analysis and financial approval prior to implementation. Epics are analysed before implementation to identify capabilities and enablers (architectural support). Epics may be combined into a single release or delivered over many releases.
Epics are identified in the project road map and are equivalent to a scope statement. Epics shall provide functional blocks that are sufficiently self-contained so as to provide business improvement in their own right. Business Epics shall provide functionality that aligns with and fully delivers upon one or more Business Requirements. Enabler Epics support the technical considerations for the business epics. Epics have the following states: Funnel, Evaluation, Backlog, Implementation and Done.       Capabilities

A Capability is a system service which is equivalent to E2E system Requirement that delivers and traces back to high level stakeholder needs. Capabilities are expressed as the benefit that the system provides the stakeholder. A Capability shall be implemented in a single Project Increment Planning and Retrospective. Capabilities are refined and split into Features. Agile principles discourage large up front design and very detailed requirements. The Capabilities should have detail which can be added in the decomposition into Features and Stories.       Features

A Feature is a Subsystem service that contributes to a stakeholder need. It is equivalent to a Subsystem Requirement.       Stories

A Story is a short description of a small piece of required functionality. Stories are written by teams to further refine the requirements. They can be implemented by a single team in an increment. They are managed in the team backlogs. Tasks can be identified to implement stories.

Thursday, September 27, 2018

What item of WIP are you limiting in a Scrum with Kanban?

  1. Even if the team is using tasks, WIP limits should primarily be applied to PBI and not tasks. Limiting tasks may be useful, but doesn't replace limiting WIP at PBI level.
  2. Flow of Value / Learnings = Flow of PBI and not the tasks 

Friday, September 14, 2018

Coaching Levels...

Not intending to sound hierarchical, agile coaching targets several layers of the management / teams.

1. Executive Coach -- CXO's
2. Enterprise Coach -- Directors
3. Agile Coach -- Senior Managers / General Managers
4. Scrum Master -- Team coach

Strategy is a hypothesis rather than a plan

Monday, August 13, 2018

Coaching Competencies

  1. Coaching and Facilitating
  2. Teaching and Mentoring
  3. Domain Mastery
  4. Technical Mastery
  5. Transformational Mastery
  6. Maintain Neutrality
  7. Serve Client Agenda
  8. Reduce Client Dependence
  9. Not Colluding to accommodate dysfunctions
  10. Signature presence / coaching stance
  11. Leadership

Thursday, August 09, 2018

Traditional vs. Agile Organizations

Traditional Organization
Agile Organization
In a traditional firm the organisation is seen as a number of separate departments, each of which is either a cost centre, like IT or HR, or a profit centre like Sales. The difference is that a cost centre doesn’t contribute directly to revenue. Costs are allocated to each cost centre, and cost efficiencies come from reducing the operating costs in the cost centres and maximising the revenue from the profit centres. Common strategies for reducing costs, especially towards the end of the financial year, are limiting travel, reducing variable headcount by laying off contractors and other temporary staff, shifting work to cheaper countries or locations (“moving the work to the people”), repurposing legacy hardware and equipment, and forcing teams to use standard components to minimise “cost per use”. Common strategies for maximising revenue are offering commissions on sales, setting aggressive quarterly targets, and offering incentives and rewards for achieving specific goals. Gains come from maximising resource utilisation, i.e. keeping people busy.

In an agile organisation—in the broader sense of business agility—the organisation is seen as an interconnected system where all departments are value-generating, either directly contributing to the final product or indirectly enabling the organisation to work more effectively. Value chains map the creation of value through the organisation, ending with meeting a specific customer need. Costs and revenues are allocated holistically across the whole value chain, and cost efficiencies come from optimising the flow of value. Common strategies for reducing costs are identifying and eliminating non-value adding activities, limiting the amount of work in process to reduce hidden inventory of work, and assembling multi-disciplinary teams to reduce handoffs and other delays (“moving the people to the work”). Common strategies for maximising revenue are working iteratively and incrementally in small batches to realise value sooner and improve Risk-adjusted Return on Capital, frequent testing of product ideas with customers to identify which work not to do, and enabling teams to choose the most effective tools to reduce their time to market. Gains come from optimising flow efficiency, i.e. keeping work moving.

Dan North

Dan North on Agile Transformation

"Transformation is not a transactional activity that starts and ends and has a budget, and it should not be treated as one". It is never finished, in the same way evolution or adaptation is never finished. The goal is rather to break free from the thinking that led to the incumbent system by introducing a new paradigm, and then to use this to achieve a new steady state where the organisation is responding quickly and effectively to external and internal feedback, behaving like a genuine learning organisation.

Lean Agile Procurement

DAYS instead of Months
NEEDS instead of Wants
ADAPTIVE instead of Fixed
PARTNERSHIP instead of Relationship
FUN instead of pain

Tuesday, August 07, 2018

DevOps Tools

Good visuals by John Cutler on why agile isn't working...

Changes to scrum

  1. Chicken and pigs
  2. Dev teams no longer "commit", they forecast
  3. Grooming replaced by refinement
  4. The three questions in daily scrum are an option, DS can be conducted in various ways as long as in the context of sprint goal.
  5. Team is responsible for daily scrum instead of scrum master

Interesting reads - Agile, Change Management and Rest...

  1. Coaching Agile Teams by Lyssa Adkins
  2. Narrative Coaching by David Clarke
  3. Nudge - Thaler and Sunstein

In favor of autonomous, feature teams

Erin Koth

I always like posing the question, "What do you do when production is down?"
You get people who have knowledge of the entire application in a room together and empower them to fix the problem.

That's the type of team you want in development, without the extreme pressure of that sort of time crunch

Thursday, August 02, 2018

REST, SOAP and CORBA -- How we got it here...


Greg Turnquist

I keep running into ideas, thoughts, and decisions swirling around REST. So many things keep popping up that make me want to scream, “Just read the history, and you’ll understand it!!!”

So I thought I might pull out the good ole Wayback Machine to an early part of my career and discuss a little bit about how we all got here.

In the good ole days of CORBA

This is an ironic expression, given computer science can easily trace its roots back to WWII and Alan Turing, which is way before I was born. But let’s step back to somewhere around 1999-2000 when CORBA was all the rage. This is even more ironic, because the CORBA spec goes back to 1991. Let’s just say, this is where I come in.

First of all, do you even know what CORBA is? It is the Common Object Request Broker Architecture. To simplifiy, it was an RPC protocol based on the Proxy pattern. You define a language neutral interface, and CORBA tools compile client and server code into your language of choice.

The gold in all this? Clients and servers could be completely different languages. C++ clients talking to Java servers. Ada clients talking to Python servers. Everything from the interface definition language to the wire protocol was covered. You get the idea.

Up until this point, clients and servers spoke binary protocols bound up in the language. Let us also not forget, that open source wasn’t as prevalent as it is today. Hessian RPC 1.0 came out in 2004. If you’re thinking of Java RMI, too bad. CORBA preceded RMI. Two systems talking to each other were plagued by a lack of open mechanisms and tech agreements. C++ just didn’t talk to Java.

CORBA is a cooking!

With the rise of CORBA, things started cooking. I loved it! In fact, I was once known as Captain Corba at my old job, due to being really up to snuff on its ins and outs. In a rare fit of nerd nirvana, I purchased Steve Vinoski’s book Advanced CORBA Programming with C++, and had it autographed by the man himself when he came onsite for a talk.

Having written a mixture of Ada and C++ at the beginning of my career, it was super cool watching another team build a separate subsystem on a different stack. Some parts were legacy Ada code, wrapped with an Ada-Java-CORBA bridge. Fresh systems were built in Java. All systems spoke smoothly.

The cost of CORBA

This was nevertheless RPC. Talking to each other required meeting and agreeing on interfaces. Updates to interfaces required updates on both sides. The process to make updates was costly, since it involved multiple people meeting in a room and hammering out these changes.

The high specificity of these interfaces also made the interface brittle. Rolling out a new version required ALL clients upgrade at once. It was an all or nothing proposition.

At the time, I was involved with perhaps half a dozen teams and the actual users was quite small. So the cost wasn’t that huge like today’s web scale problems.

Anybody need a little SOAP?

After moving off that project, I worked on another system that required integrate remote systems. I rubbed my hands together, ready to my polished CORBA talents to good use again, but our chief software engineer duly informed me a new technology being evaluted: SOAP.


The thought of chucking all this CORBA talent did not excite me. A couple of factors transpired FAST that allowed SOAP to break onto the scene.

First of all, this was Microsoft’s response to the widely popular CORBA standard. Fight standards with standards, ehh? In that day and age, Microsoft fought valiantly to own any stack, end-to-end (and they aren’t today???? Wow!) It was built up around XML (another new acronym to me). At the time of its emergence, you could argue it was functionally equivalent to CORBA. Define your interface, generate client-side and server-side code, and its off the races, right?

But another issue was brewing in CORBA land. The OMG, the consortium responsible for the CORBA spec, had gaps not covered by the spec. Kind of like trying to ONLY write SQL queries with ANSI SQL. Simply not good enough. To cover these gaps, very vendor had proprietary extensions. The biggest one was Iona, an Irish company that at one time held 80% of the CORBA marketshare. We knew them as “I-own-ya'” given their steep price.

CORBA was supposed to cross vendor supported, but it wasn’t. You bought all middleware from the same vendor. Something clicked, and LOTS of customers dropped Iona. This galvanized the rise of SOAP.

But there was a problem

SOAP took off and CORBA stumbled. To this day, we have enterprise customers avidly using Spring Web Services, our SOAP integration library. I haven’t seen a CORBA client in years. Doesn’t mean CORBA is dead. But SOAP moved into the strong position.

Yet SOAP still had the same fundamental issue: fixed, brittle interfaces that required agreement between all parties. Slight changes required upgrading everyone.

When you build interfaces designed for machines, you usually need a high degree of specification. Precise types, fields, all that. Change one tiny piece of that contract, and clients and servers are no longer talking. Things were highly brittle. But people had to chug along, so they started working around the specs anyway they could.

I worked with a CORBA-based off the shelf ticketing system. It had four versions of its CORBA API to talk to. A clear problem when using pure RPC (CORBA or SOAP).

Cue the rise of the web

While “rise of the web” sounds like some fancy Terminator sequel, the rampant increase in the web being the platform of choice for e-commerce, email, and so many other things caught the attention of many including Roy Fielding.

Roy Fielding was a computer scientist that had been involved in more than a dozen RFC specs that governed how the web operated, the biggest arguably being the HTTP spec. He understood how the web worked.

The web had responded to what I like to call brute economy. If literally millions of e-commerce sites were based on the paradigm of brittle RPC interfaces, the web would never have succeeded. Instead, the web was built up on lots of tiny standards: exchanging information and requests via HTTP, formatting data with media types, a strict set of operations known as the HTTP verbs, hypermedia links, and more.

But there was something else in the web that was quite different. Flexibility. By constraining the actual HTML elements and operations that were available, browsers and web servers became points of communication that didn’t require coordination when a website was updated. Moving HTML forms around on a page didn’t break consumers. Changing the text of a button didn’t break anything. If the backend moved, it was fine as long as the link in the page’s HTML button was updated.

The REST of the story

In his doctoral dissertation published in 2000, Roy Fielding attempted to take the lessons learned from building a resilient web, and apply them to APIs. He dubbed this Representational Transfer of State or REST.

So far, things like CORBA, SOAP, and other RPC protocols were based on the faulty premise of defining with high precision the bits of data sent over the wire and back. Things that are highly precise are the easiest to break.

REST is based on the idea that you should send data but also information on how to consume the data. And by adopting some basic constraints, clients and servers can work out a lot of details through a more symbiotic set of machine + user interactions.

For example, sending a record for an order is valuable, but it’s even handier to send over related links, like the customer that ordered it, links to the catalog for each item, and links to the delivery tracking system.

Clients don’t have to use all of this extra data, but by providing enough self discovery, clients can adapt without suffering brittle updates.

The format of data can be dictated by media types, something that made it easy for browsers to handle HTML, image files, PDFs, etc. Browsers were coded once, long ago, to render a PDF document inline including a button to optionally save. Done and done. HTML pages are run through a different parser. Image files are similarly rendered without needing more and more upgrades to the browser. With a rich suite of standardized media types, web sites can evolve rapidly without requiring an update to the browser.

Did I mention machine + user interaction? Instead of requiring the client to consume links, it can instead display the links to the end user and let he or she actually click on them. We call this well known technique: hypermedia.

To version or not to version, that is the question!

A question I get anytime I discuss Spring Data REST or Spring HATEOAS is versioning APIs. To quote Roy Fielding, don’t do it! People don’t version websites. Instead, they add new elements, and gradually implement the means to redirect old links to new pages. A better summary can be found in this interview with Roy Fielding on InfoQ.

When working on REST APIs and hypermedia, your probing question should be, “if this was a website viewed by a browser, would I handle it the same way?” If it sounds crazy in that context, then you’re probably going down the wrong path.

Imagine a record that includes both firstName and lastName, but you want to add fullName. Don’t rip out the old fields. Simply add new ones. You might have to implement some conversions and handlers to help older clients not yet using fullName, but that is worth the cost of avoiding brittle changes to existing clients. It reduces the friction.

In the event you need to REALLY make a big change to things, a simple version number doesn’t cut it. On the web, it’s called a new website. So release a new API at a new path and move on.

People clamor HARD for getting the super secret “id” field from a data record instead of using the “self” link. HINT: If you are pasting together URIs to talk to a REST service, something is wrong. It’s either your approach to consuming the API, or the service itself isn’t giving you any/enough links to navigate it.

When you get a URI, THAT is what you put into your web page, so the user can see the control and pick it. Your code doesn’t have to click it. Links are for users.

Fighting REST

To this day, people are still fighting the concept of REST. Some have fallen in love with URIs that look like, thinking that these pretty URLs are the be-all/end-all of REST. Yet they code with RPC patterns.

In truth, formatting URLs this way, instead of as or is to take advantage of HTTP caching when possible. A Good Idea(tm), but not a core tenet.

As a side effect, handing out JSON records with {orderId: 523} has forced clients to paste together links by hand. These links, not formed by the server, are brittle and just as bad as SOAP and CORBA, violating the whole reason REST was created. Does Amazon hand you the ISBN code for a book and expect you to enter into the “Buy It Now” button? No.

Many JavaScript frameworks have arisen, some quite popular. They claim to have REST support, yet people are coming on to chat channels asking how to get the “id” for a record so they can parse or assemble a URI.

BAD DESIGN SMELL! URIs are built by the server along with application state. If you clone state in the UI, you may end up replicating functionality and hence coupling things you never intended to.

Hopefully, I’ve laid out some the history and reasons that REST is what it is, and why learning what it’s meant to solve can help us all not reinvent the wheel of RPC.

Tuesday, July 24, 2018

Refactoring techniques (courtesy

Refactoring techniques

Composing methods

Much of refactoring is devoted to correctly composing methods. In most cases, excessively long methods are the root of all evil. The vagaries of code inside these methods conceal the execution logic and make the method extremely hard to understand – and even harder to change.
The refactoring techniques in this group streamline methods, remove code duplication, and pave the way for future improvements.

Moving Features between Objects

Even if you have distributed functionality among different classes in a less-than-perfect way, there is still hope.
These refactoring techniques show how to safely move functionality between classes, create new classes, and hide implementation details from public access.

Dealing with Generalisation

Abstraction has its own group of refactoring techniques, primarily associated with moving functionality along the class inheritance hierarchy, creating new classes and interfaces, and replacing inheritance with delegation and vice versa.