Skip to main content

Notes to Self - A Tale of Two Transformations: Bringing Lean and Agile Software Development to Life

Notes taken from reading the book "A Tale of Two Transformations: Bringing Lean and Agile Software Development to Life"  by  Michael K. Levine  - Producitivty Press - 2012


If a software development organization needs to be changed, what is the best way to go about  it?

In this book “A Tale of Two Transformations: Bringing Lean and Agile Software Development to Life”, the author Michael K. Levine  talks about how Lean and Agile were used to improve the software development performance of two organizations. He tells the story of the transformation of two different organizations through two protagonists whose people management styles are quite different.The parable format allows bringing in the human elements ( the fears, the egos and the greed) and makes the story all the more interesting and realistic. This is because anyone who has undertaken a change will know that bringing about  change without handling the human elements is just talking theory. 

The organizations that need to undergo change are quite different from each other. One organization's (MCCA) operation and product development were chaotic and depended entirely on the heroics of a few dedicated individuals. It didn't have a product strategy and road map in place. Sales team basically sold contracts with strong penalties for non-delivery, without considering implementation in  mind. Sales team bonus was linked to the sales contracts closed and hence contract closure (even at a loss to the organization) was an usual practice. Since there was no product road map in place and what a client wanted determined the product strategy, the operations and development team were at the receiving end of this practice of sales team. 

MCCA's challenge was to standardize and improve the operations and make reliable the product development (with the help of a long term strategy and a road map).

The second company FinServia was a newly independent division of a much larger company. Its product and services had become so  rigid/in-flexible that customers started leaving. And the few customers who still remained did so to avoid switching costs. The company had made the mistake of outsourcing technology work to a vendor. The vendor had implemented a waterfall based process. Hence software development and operations suffered from too much of process that was highly regimented, slow to change, late to market and very behind the competition. All this was kind of acceptable when the company was a part of a larger organization. But once it became independent,  FinServia was in a perform or perish situation.

FinServia's challeng was to loosen the grip of bureaucracy and waterfall process and accelerate and make reliable its product development. 

Basically the author serves two  organizational structures that are in need of change ( for different reason) and explains how the organizations go about the change, with the help of Protagonists Wes (MCCA) and Mary (FinServia). in doing so, the author evolves two models of implementing Lean/Agile change; one is particiaptive ( People Driven) and other is directive ( Drive people).

The table below shows the current status of the organizations

Characteristic
(MCCA)
(FinServia)
Current Performance
Uneven
Poor
Urgency of Change
Moderate; possible to stumble along
High; failure assured if not successful
Technical Expertise of Leader
Low to moderate
High
Style of Leader
Participative
Directive
Staff Trajectory
Growing
Shrinking
Individuals Critical to Mission
Some key leaders and technicians
Few if any
Ability of Organization to Reform Itself, Given Support and Chance
Possible; not set in any particular way; see need to change
Unlikely
Support from Senior Executives
Supportive, but wary
Supportive and trusting

The author explains that a(ny) software development organization has to deal with people, process, and tools to bring about a change. It takes all three dimensions to succeed, with each reinforcing and supporting the other.  One needs experts , organized into appropriately focused teams, working in a culture dedicated to problem solving and elimination of waste.  He uses the following diagram to represent the same.
Lean and Agile Development

The author explains how the different approaches chosen fit the requirement and also the people management style of protagonists

Wes (MCCA) chose the people driven approach. Basic idea of this approach is to engage existing team members in the change to gain their commitment and participation to drive transformation as a team.
This approach relies on setting a compelling vision for change. Having the necessary skills to communicate and gain commitment and training and mentoring team members to help them make good directional decisions. The potential downside to this approach is that the team members don’t get it and the needed change happens too slowly or not at all.

Mary (FinServia) chose the ‘Drive people approach’.  This approach puts less initial value on team members engagement and commitment and stresses on directional change imposed by the leader. This requires a leader who knows what she wants atleast in the initial stages of change and a stomach for atlease temporary disruption. Initially the focus was more on  implementing new processes & tools, change the organization and get new people on board and existing people in new or changed roles.

The diagram below shows how the approaches rank on different aspects of change.


Approaches to Lean/Agile Transformation
Any change needs a vision and leadership to implement the vision. Leadership also needs to put in the right organization structure, get the right people in  the right positions and enforce processes with the help of toolsKey steps followed and decisions taken regarding these points are explained in detail.

To Summarize, most books introduce theory by providing abstract details. This book approaches the problem differently, takes the reader through the specific details of implementation in two totally different organizations with the people and political aspects. And where ever needed, theoretical aspects of Agile and Lean are also discussed and key decisions are explained in detail. This has the advantage of making the transformation realistic and story stick. Recommended reading.


Comments

Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …