I write about Software Development, General management and what interests me in Science and Maths. This is based on my experience as a Project Manager and what i read (books, articles, blogs).
If you are wondering about the 'everything else' part along with Project and General Management, i have deliberately kept it so that i can write about anything and everything i feel like. And 'everything else' is inspired by Hitch Hiker's Guide to the Galaxy Series by Douglas Adams. :)
Search This Blog
Lessons Learnt - A Tale of Two Transformations: Bringing Lean and Agile Software Development to Life
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 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
Customer FocusLean 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 SimpleStart 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 PracticesOne 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 PartnershipsMigrating 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.
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…
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…
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 …