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). 

 

People

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 Elsewhere: Giving 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

 

Organization

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

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 (http://en.wikipedia.org/wiki/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

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