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 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.
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.
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 tools. Key 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.
Approaches to Lean/Agile Transformation |
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.
No comments:
Post a Comment