Saturday, December 21, 2013

Lessons Learnt - A Tale of Two Transformations: Bringing Lean and Agile Software Development to Life

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

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. The protagonists in the book also followed the same path. Lessons learnt from the transformation to a Lean and Agile Organization is given below. 

The lessons below will make more sense if the review is read first.

Vision And Leadership

Set a Simple and Compelling Vision: The vision must be business focused above all else, and it should be measured by success in meeting the needs of customers, shareholders, team members, and the community.  Cries such as "we need to be Agile" or "let's be Lean to cut out the waste" aren't terribly motivating, and they emphasize the means, rather than the goal.


Build a Supporting Coalition:  No one likes change and so Change draws opposition. As you start a change initiative, think strategically about which leaders you would like firmly on your side, and reach out to them to ask for commitment and help.


Make a Plan, Specific to Your Organization’s Reality: A change plan, tailored to the organizational requirements and the change agent’s position in it, should be made. It should simple and easy to communicate.  Note that the process of building organizational support for change is critically important and goes a long way in making the plan a success.

Use Integrating Events: Any plan for change should have an immovable target for the team, with a public commitment to deliver.  This target is called an integrating event since it brings together the different aspects of the change methodology chosen. This is very important as the event becomes a check point for all stakeholders to measure the progress.


Accelerate Delivery: The promise of Lean and Agile development is faster, cheaper, higher-value delivery. In any Lean and Agile transformation, the team must demonstrate this right out of the box. The Agile Manifesto puts emphasis on working code over documents, so demonstrate that—fast! 


Don't Re-invent the wheel: Remember that Lean product development is mostly about learning.  Rather than reinventing everything for yourself, draw on the experience of others, through reading, attending conferences, hiring, and using consultants. Use consultants to help accelerate learning, not to do for you what you could do for yourself.


Encourage Engagement and Debate, within Limits:  Effective facilitative leaders ensure that their teams have their fingerprints on the critical decisions that the team will be expected to implement. This requires that teams be allowed to engage with ideas, to express themselves, and to work through decisions together. There is an element akin to parenting in this dimension of leadership. The team needs to become self-sufficient, as does a child, but there always remains a role for the parent.

Understand Your Boundaries: In every business situation, there are boundaries that proscribe certain actions and require others. Sometimes, the boundaries are people (dealing with people or  deliverables or  the process . Finally, sometimes these boundaries are explicit, but sometimes they're unstated. It's best to explicitly understand and accommodate or work to move the boundaries, rather than run into them and be surprised.

Do the Math: Change is always about money since decisions involve saving money (Speeding up delivery to save or make money) or spending money (improving training and learning) to save money. As you begin or work to sustain a change initiative, do the math on the money, and communicate it explicitly to those who need to understand and approve (i.e., Management, Finance, Accounting, your customers). 



Give Existing Leaders a Chance: When considering the state of an organization (if it's not so good. ‥‥), it's tempting to assume the inadequacy of the people who comprise it. That's probably true to some extent: they may not possess necessary competence. Give them a chance! Make it clear that change is expected, expose them to opportunities to learn, give them support to implement new ideas. The business knowledge and relationships in the existing team are invaluable, if they can be harnessed to power your change.

Let Obstructionists Continue Their Careers ElsewhereGiving existing team members a chance doesn't mean giving them infinite chances, however. As a manager, once you reach a confident conclusion that a team member won't sign up for the new culture, or doesn't have the skill set or the ability to adapt well, do both yourself and the team member the kindness of helping him or her to move on to another organization.


Get the right mix of people: Many a times, It is very difficult for a group of people to make fundamental change to themselves. Additionally, if a group does not have the critical Lean and Agile values, the process of development can be extended and uncertain. This is not to say that change without adding new people to the mix is impossible. Progress can certainly be made, if they have management support and access to external help, . Hence, it is the job of the change leader to ensure that the right mix of old and new people is arrived at, to help the change move forward.


Get People to Do It themselves: People learn best by doing, not by being told how to do something. And they tend to implement ideas that they were involved in originating more effectively than those directed at them. Finally, the very nature of Lean and Agile development is about getting people to be expert at their disciplines. Hence change leaders should take this risk.


Build Chief Engineers, but Adapt to the Situation at Hand: The practice of Lean product development at Toyota depends on the Chief Engineer, or CE, but that structure is not necessarily a good fit, or even possible, in many organizations. The essence of the CE is the combination (in one person) of engineering, marketing, organizational, and leadership skills. Most organizations may not have such candidates. Hence the right arrangement for your situation depends. But don't give up on the idea of creating people who have CE characteristics—multi disciplinary knowledge combined with organizational clout. 


Teach to Lead, and Lead by Teaching: Leadership is a combination of intrinsic personal characteristics and learned behavior. Leadership can be taught, and for a Lean/Agile environment, it must be. Lean and Agile leaders must be experts, they must teach, they must listen, they must help their people work together effectively, they must insist on rigorous decision making. The idea of leaders as teachers is central to Lean, as practiced at Toyota and other companies. This means that they must have more or different knowledge than their team members, and that they must be expected and taught to teach. Find opportunities to reinforce these ideas.


Spreading Knowledge—Institutionalize Knowledge and Learning: The best way to ensure good decisions are made is to ensure that team members have the expertise (along with the motivation and support) to make them. Match the knowledge level required of the team to the scale of the problem being faced. And if you want to be the best, you have to be a learning organization.

Build Your Capability before You Build Your Software:  An organization's ability to deliver software projects depends on its people, process, and tools. If you want your organization to be effective at software development, don't focus solely on the projects in flight; that is too late. Instead, focus on the people, processes, and tools in the organization, and prepare to be successful at the next generation of projects. (Of course, don't ignore or give up on the current projects).  Suggested reading; Equip More and Ask More



Customer Focus Lean thinking demands that customer value be understood and that value be delivered with no waste. This requires that the customer understanding be well linked to product development. LPD relies on the Chief Engineer, combining in one person (with a small team) the engineering, organizational, customer focus, and leadership skills required. Agile posits the Product Owner, someone able to speak definitively on behalf of the customer and the organization with respect to priorities and product features.


We Are All "The Business" Whatever organizational structure you have or choose, Lean/Agile requires that everyone be focused on value creation and end-to-end flow. The change leader has to drive this message hard.



Process Can Drive Lean/Agile Change, but It's Not Enough by Itself: Lean or Agile change programs that seek to move an entire organization to become Lean or Agile by changing the required methodology, forcing people to do scrums, or the like can result in improvements, but they are unlikely to be sustainable. What sustains the improvements is the understanding that LPD is about appropriately integrating people, processes, tools and technology to add value to the customer and society. And this understanding only comes through learning Lean and Agile Principles and not just by merely following some processes.


Start Slow and Simple Start with your own understanding of Lean and Agile principles (for example, by reading a book on the topic) and determine where the biggest benefit to your projects can be derived. Build a backlog, hold daily scrum meetings, build a knowledge sharing website and lunch and learns, begin doing test-driven development. You can't go from where you are today to where you want to be quickly, but you can start the journey. Remember that the journey of a thousand miles starts with a single step.


PDCA Yourself! Plan, do, check, act. PDCA ( )  applies to your transformation effort as to any process improvement endeavor. Your situation, your goals, and your team are unique, so any advice or plan is probably only partially correct and hence has to be continuously revisited till the goal is met.


Don't Overdo Methodology: Methodology should be considered a tool for learning, not a requirement for compliance.  Let the team decide what is right for them and let it not be strait jacketed by methodology. The goal is to have a team of towering technical experts, rigorously making good decisions, informed by customer and shareholder value, adjusting continuously as they learn. 


But Do Insist on Some Basic Practices One of the foundational values of LPD is towering technical competence. Each of us steeped in product and software development no doubt has some very strong beliefs (call it technical competence) in certain processes that must be done to ensure success, and as leaders, we have an obligation to teach our teams to adopt these processes. It is poor management to dictate detailed process to a product development team. There must be a balance between empowerment and leadership



Tools Can Help, but Be Careful!  It is suggested that people start out with simple tools. This is because since tools are advantageous,people may get carried away and spend too much time understanding complex tools. Hence it is suggested that people start out with simple tools

Vendor Partnerships Migrating to Lean/Agile software development in many organizations will involve vendor relationships. Sometimes, moving in a Lean/Agile direction can require fundamental changes in existing relationships, whereas in other cases, only modest tweaks are needed. Change Leaders should Work hard to find a win-win relationship and remember that  dictating change on unwilling partners is unlikely to bring the results you seek. 


*All images are taken from the net

Friday, December 20, 2013

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

Current Performance
Urgency of Change
Moderate; possible to stumble along
High; failure assured if not successful
Technical Expertise of Leader
Low to moderate
Style of Leader
Staff Trajectory
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
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.