13 points from Reading a Podcast :-) On the principles and pitfalls of agile development

Note: This makes for an excellent read. If you like the podcast, listen to it or if you are like me, read the transcript of the podcast here.

The following points stand out.

1. It is very difficult when a part of the organization is agile and rest of the organization continues in the normal way of functioning. This introduces a dissonance or an impedance mis-match ( to be more

technical).

2. Waterfall is not bad and it was very useful in a particular context “It’s not that waterfall is bad. Actually, waterfall is a perfectly fine way of doing things. There were good reasons why it emerged when the computer and mainframes and the cost of doing things were such that it required a lot of advanced planning, a lot of coordination, and a lot of rigidity to make sure that things were done in a way that dependencies were addressed properly up front.”

3. The need for Agile now, “The reality is, in today’s context, with technology being more flexible and cheaper, you have the ability to think very differently about how you bring technology to market.”

4. On organizations adopting agile principles “I do think one of the beautiful things about these principles is you need to think of them in a holistic way. You can’t just cherry pick a few of them”

5.On the first principle of Agile Adoption, “At the core, you need to be putting the customer first. You need to be clear on who the customer is, what problem you’re trying to solve, what matters to the customer, and prioritize. Always come back to who the customer is. In some cases, the customer can be the internal customer. But often, you need to make sure that it’s the external customer.In typical organizations, the distance between the customer and the people doing the coding is eight layers of translation. That can only lead to wrong prioritization, compromise, and, in the end, your likelihood of delighting the customer and doing something that’s “aha” is reduced. That’s principle number one and incredibly important.”

6. On the second principle of Agile Adoption, "The second principle that I would add is around how to focus on people interactions versus process. it’s about bringing the customer to the table. It’s part of the interaction of processes that takes away so much of the focus on just checking a box—to more of a focus on how to serve our customers and get to the right solutions for them."

7. On the third principle of Agile Adoption, “I think a third principle that is very important is welcoming change—so removing the barriers that if you change, [the idea that] if there’s failure, that something was wrong. Rather to turn it around and say, we’ve learned something. We’re going to integrate that learning into the next iteration.”

8. On team empowerment, “The fourth principle, I’d say, is to empower the team. The team knows more about the customers, it knows more about what it can do. If you make it autonomous, within some boundaries, you can have something special.  We’re going to let the people who are closest to the problem, closest to the customer, make the trade-off within the scope that we’ve agreed is the scope that they can operate in. That’s what makes it agile. That’s what makes it speedy. That’s what makes it flexible.”

9. On the whole business running in an agile manner, “Unless the whole business is operating in an agile manner, you’ve always got this layer of interaction between agile teams and, let’s say—I don’t want to pick on finance but—the finance function or control functions that may not be used to this way of operating. Is that something that organizations need to look out for?”

10. On bringing the rest of the organization along in the Agile Journey, “ bringing the rest of the organization along, because it’s not a one-time effort, it’s not a one-time transformation, it’s a journey. You have to bring every part of the organization along so that you’re speaking a common language and so that you’re shifting the way that you operate as a whole.”

11. The concept of Sunk Cost “I also see many organizations, where they’ll get the input that what they’re building is not right, and they continue to invest in it just because they’ve already invested x amount of dollars.”

12. The typical problem that we see in many organizations, cherry picking on agile principles to implement “... if you assign a product owner that’s not an empowered product owner—he or she still has to go to 50 different people to be able to make a decision on what experience to deliver to your customer. These are the things that, if you experiment with agile and start to cherry pick—and then on top of that you try to scale that approach, which is not truly agile—it’s worse than not doing agile at all, because you’re confusing the organization with “I think I’m agile,” but I’m still following the traditional way of working, and now we’re scaling this.”

13. On the three dimensions of a product owner

“A product owner is a critical role, and there is a debate in the industry around who plays the role, what is it. For me, I see it as a linchpin role, because it’s the core for these agile teams. There’s a couple of things to highlight.

One, product owners represent the customers. They understand their customers. They set the vision for their customers. They dream about their customers’ experience and the functionality that they want to deliver to them. They help to drive the team toward the vision that it has and encourage it as it goes on.

Second, product owners have what I call organizational capital. They’re able to influence the organization and bring it along on their vision of where they want to go. As they’re thinking about what they need to deliver in terms of functionality, they start to pull in the marketing team: How do you start to share the vision? The compliance team: How do we start to build the vision together? So, they start to rally the troops on the vision that they have for their customers.

The third one is, it is a leadership role. They help to guide the team and they are the leaders for how to make sure that we’re exciting our team members and that they’re rallying around the vision that they have. Because if you don’t put in the efforts that you need in terms of getting the right person for the role, it ends up being a waterfall team, because the person that you assign will just continue in the traditional way of thinking and guide the team in that direction."

* Image Source : https://twitter.com/lhamerlinck/status/676715855334400001

Notes to Self : Intelligent Digital Mesh - Gartner Top 10 Strategic Technology Trends for 2018

Note: I have given below my notes from reading Gartner’s strategic Technology Trends for 2018. I see that some of the ideas, like AI foundation, analytics and event driven apps can be explored for any transaction based application.  While the names may sound different, the underlying concepts are familiar 

According to Gartner, this mesh is  “Enabled by Digital Models, Business Platforms and a Rich, Intelligent set of Services to Support Digital Business.”

Following is how the article defines Intelligent, Digital and Mesh

Intelligent: How AI is seeping into virtually every technology and with a defined, well-scoped focus can allow more dynamic, flexible and potentially autonomous systems.

Digital: Blending the virtual and real worlds to create an immersive digitally enhanced and connected environment.

Mesh: The connections between an expanding set of people, business, devices, content and services to deliver digital outcomes.

The 10 trends are categorized under one of the above category as given below

Intelligent

1. AI Foundation
2. Intelligent apps and analytics
3. Intelligent Things

Digital

4. Digital Twins
5. Cloud to the Edge
6. Conversational Platform
7. Immersive Experience

Mesh

8. Blockchain
9. Event-Driven
10. Continuous Adaptive Risk and Trust

I have given below the key points of each trend .

Intelligent

Trend No 1:  AI Foundation

The scope of general AI ( where the system could magically perform any task an human being could do and learn ) is speculative at the best. Organizations are better off to focus on narrow AI ( highly scoped machine learning solutions with suitable algorithms for optimization ) since that is where the action is right now.

Trend No 2: Intelligent Apps and Analytics

According the Gartner, AI has become the next major battleground in a wide range of software and service markets, including aspects of ERP. “Challenge your packaged software and service providers to outline how they’ll be using AI to add business value in new versions in the form of advanced analytics, intelligent processes and advanced user experiences”. Where the focus should be to take care of the human angle is made clear by the statement “Explore intelligent apps as a way of augmenting human activity, and not simply as a way of replacing people” 

Trend No 3:  Intelligent Things

“Intelligent things use AI and machine learning to interact in a more intelligent way with people and surroundings.” is the definition.  While  some intelligent things wouldn’t exist without AI, other existing things (i.e., a camera) are made intelligent with AI (i.e., a smart camera.) . 

As more and more intelligent things proliferate , the focus will shift from stand-alone things to collective things or swarms. A car being able to communicate to other cars, get input about traffic and weather conditions and make decisions is a classic example of this proliferation. 

Safe Swarm is a recent concept introduced by Honda (co-operative mobility eco-system) is a good example.

Digital

Trend No. 4: Digital Twins

“A digital twin is a digital representation of a real-world entity or system. In the context of IoT, digital twins are linked to real-world objects and offer information on the state of the counterparts, respond to changes, improve operations and add value.” While this can help with feedback about how products are managed , in the short term, in the longer term, the feedback can encompass improvement suggestions and usage changes.

While not immediately feasible, the long term prospects of this idea is very enticing. To quote from the article,  “Over time, digital representations of virtually every aspect of our world will be connected dynamically with their real-world counterparts and with one another and infused with AI-based capabilities to enable advanced simulation, operation and analysis,”. 

I am not sure if I can have a digitial twin of Ramanan that will help me practice yoga better in the absence of my teacher ;-)

Trend 5 : Cloud to the Edge 

“Edge computing describes a computing topology in which information processing and content collection and delivery are placed closer to the sources of this information.”   To decrease latency, the apps will be deployed in the cloud server which is closer to its user group. This will happen automatically with no human intervention. And depends on the network traffic and scaling requirement.  There are already companies that provide such services and www.machineshop.io is one example.

Trend No. 6: Conversational Platforms

To quote from the article “Conversational platforms will drive a paradigm shift in which the burden of translating intent shifts from user to computer. These systems are capable of simple answers (How’s the weather?) or more complicated interactions (book a reservation at the Italian restaurant on Parker Ave.)“.  Amazon Alexa, Google Now Microsoft Cortana and Apple Siri are only the start and the potentials are enormous for conversational platforms when they are applied along with AI and AR.

Trend No. 7: Immersive Experience

“Augmented reality (AR), virtual reality (VR) and mixed reality are changing the way that people perceive and interact with the digital world.” When this is  combined with conversational platforms, a fundamental shift in the user experience to an invisible and immersive experience will emerge. Application vendors, system software vendors and development platform vendors will all compete to deliver this model. Apple’s release of ARkit and iPhone X, Google’s Tango and ARCore, make AR and MR an interesting area

Mesh

Trend No. 8: Blockchain

As per the article, while the focus is now on financial services, the potential applications in other areas like government services, healthcare , supply chain has to be explored.  

And for those who want to implement Blockchain, here is a word of caution ”A practical approach to blockchain demands a clear understanding of the business opportunity, the capabilities and limitations of blockchain, a trust architecture and the necessary implementation skills. Before embarking on a distributed-ledger project, ensure your team has the cryptographic skills to understand what is and isn’t possible. Identify the integration points with existing infrastructures, and monitor the platform evolution and maturation. Use extreme caution when interacting with vendors, and ensure you are clearly identifying how the term “blockchain” is being used.”

Trend No. 9: Event-Driven

An event is defined as a state change that is of interest and a moment is a combination of such events and such a moment calls for a specific action or response. When this events happen across applications or business lines, technologies like AI, iOT make it easier to detect and respond. A quote from the article is given below.

“Business events reflect the discovery of notable states or state changes, such as completion of a purchase order. Some business events or combinations of events constitute business moments — a detected situation that calls for some specific business action. The most consequential business moments are those that have implications for multiple parties, such as separate applications, lines of business or partners.“

Trend No. 10: Continuous Adaptive Risk and Trust

When the levels of digitalization keeps increasing, so does the threat potential. The traditional ways of risk management and security doesn’t help. The risk management should be real time, continuous and adaptable. Gartner introduces the idea of CARTA. Quoting from the article, “Continuous adaptive risk and trust assessment (CARTA) allows for real-time, risk and trust-based decision making with adaptive responses to security-enable digital business.“

The article also suggests couple of ways to make CARTA a reality. It suggests that “Integrating security into your DevOps efforts to deliver a continuous “DevSecOps” process and exploring deception technologies (e.g., adaptive honeypots) to catch bad guys that have penetrated your network are two of the new techniques that should be explored to make CARTA a reality.”

The complete article can be read here at - http://www.gartner.com/smarterwithgartner/gartner-top-10-strategic-technology-trends-for-2018/

Specialists needed for any Change

How many type of people do you need to bring about a change ? KurtVonnegut(1922-2007), an American writer has an interesting answer through his book Bluebeard. In the book, one of the characters by name Paul Slazinger is working on a non-fiction titled The Only Way to Have a Successful Revolution in Any Field of Human Activity and claims to have an answer to the question.

For what it is worth: Slazinger claims to have learned from history that most people cannot open their minds to new ideas unless a mind-opening team with a peculiar membership goes to work on them.

According to Vonnegut, any revolution or change needs a team consisting of three types of specialists.

The team must consist of three sorts of specialists, he says. Otherwise, the revolution, whether in politics or the arts or the sciences or whatever, is sure to fail.

 The first specialist is the person who comes up with a rare and special idea

The rarest of these specialists, he says, is an authentic genius -- a person capable of having seemingly good ideas not in general circulation.

Vonnegut says that the person on his will be considered a madman or Lunatic. Though a genius, this person is someone with very poor people skills. you can think of Howard Roark's mentor Henry Cameron. Cameron is a classic example of a person who had a revolutionary idea, but was repudiated by the society and is shown as a failure in the book. Tesla can be another example.

"A genius working alone," he says, "is invariably ignored as a lunatic."

The second specialist is the one who is already trusted by the society and one who also understands the idea , the need for it and certifies the idea. This allows the idea to get an entry in the minds of people. This is important because the person is already trusted and we, human beings are wired to believe in people whom we already trust

The second sort of specialist is a lot easier to find: a highly intelligent citizen in good standing in his or her community, who understands and admires the fresh ideas of the genius, and who testifies that the genius is far from mad.

 On his own, this person who is trusted by the society may hope for a change, but can't do anything more because he/she doesnt have the know-how to bring about the change. This person can be looked at as the coach who finds the sparkle in a person

"A person like that working alone," says Slazinger, "can only yearn out loud for changes, but fail to say what their shapes should be."

Now that the idea has gained the trust of important persons, it is necessary to take it to a wider set of people. For that we need people who can communicate the idea to people in the simplest possible terms and enter the communicator

The third sort of specialist is a person who can explain anything, no matter how complicated, to the satisfaction of most people, no matter how stupid or pigheaded they may be.

 On his own, the communicator doesn't amount to much because he doesnt have a great idea to communicate. In the absence of the genius and the great idea, this person will be doing a good job, communicating a bad idea. Vonnegut equates such a person to a turkey full of stuffing :-)

"He will say almost anything in order to be interesting and exciting," says Slazinger. "Working alone, depending solely on his own shallow ideas, he would be regarded as being as full of shit as a Christmas turkey."

To sum-up, to bring in a change, the following three types are needed and without each of them, the change will not happen. If you want to talk about Change Management in mathematical terms, the relation is an Logical And operator :-)

• The first one is a genius who comes up with an original idea.
• The second one is a person who already is trusted by the society and also yearns for a change, but can't bring about the change on his own since he lacks the idea. This person helps the idea to gain acceptance in the minds of important people,
• The Third person is the communicator . The idea has to be communicated to a larger audience and the communicator who has the ability to simplify even complex ideas and make it understandable to people, plays a key role.

Wicked Problems and Tame Problems

I  was  searching the web on "Software Project Failures", trying to understand (!!) why projects fail in spite of having the best people, processes and intention in place. I came across this categorization of Wicked and Tame Problems in a paper titled "Dilemmas in a General Theory of Planning*". What follows below is the notes taken from reading that paper. 

0-0-0-0

The problems that scientist and engineers are usually focused on are known as Tame Problems. An example can be solving an equation in mathematics or analyzing the structure of an unknown compound in chemistry or solving a chess puzzle. For each, the objective is very clear and it is also clear whether the problem is solved or not.

The authors propose that the kind of problems in the public domain , for e.g. public transportation, education, public health and policy decisions  are inherently different from the problems that scientists deal with. The problems in natural sciences are definable and may have a solution that can be found with the effort varying based on complexity of the problem.

For the problems in the public domain, what is to be solved is not clearly defined and whether a solution is reached or not is difficult to ascertain. Problems with such characteristics are called Wicked Problems.

The authors of the paper have provided at least ten distinguishing properties of planning type problems that are given below.

#1 There is no perfect definition of a wicked problem: While for a Tame Problem, like solving an equation or a Chess puzzle, an exhaustive statement containing all the information needed for a person to solve the problem can be provided, it is not possible with wicked problems.  Wicked Problems depend upon a person's idea for solving it. For e.g. a statement like 'we need to solve the traffic problem in a city' can be interpreted as need for more flyovers or need for a better public transport system or the need to de-congest the city by developing a nearby location.  In each of the options proposed, the solution actually depends on the option chosen. So for wicked problems, the formulation of a problem is the problem! 

#2 Wicked problems have no stopping rule: In case of solving a mathematical equation or a chess puzzle, the problem solver knows when he has done his job. This is not possible with wicked problems. Since the problem varies on how it is defined ( refer #1) a planner can always do better. Some additional investment of time and money may mean a better solution. Usually the planner working on the wicked problem terminates work because he has run out of time or money or both.

#3 Solutions to a wicked problems are not true or false, but are good or bad: When solving an math equation or a chess puzzle, we can objectively decide whether the proposed solution is right or wrong. The proposed solution can also be checked by an independent authority. For wicked problems, there are no true or false answers. People's judgment of a wicked problem varies with their personal interests, their values and ideology. The assessment of a proposed solution is expressed as good or bad or better or worse or satisfying or good enough.

#4 There is no immediate and no ultimate test of a solution to a wicked problem: With wicked problems, any solution, after implementation, will generate waves of consequences over an extended - virtually unbounded - period of time. For e.g. the consequence of building a fly over or setting up a train network through a city can't be completely understood till the solution is implemented and the fly over or train network seen in action.  In contrast, for tame problems, the test of a solution is entirely under the control of a few who are interested in the problem

#5 Every attempt to a wicked problem is a "one-shot operation": There is no opportunity to learn by trial and error: As mentioned in #1, every solution to a wicked problem is unique. And each solution has its own consequence. We can't build a fly over, see how it works and then modify it because of unsatisfactory performance or un desired consequence. This is because every decision to reverse a decision or correct it poses another set of wicked problems.

#6 Wicked Problems do not have an exhaustive set of potential solutions: Chess has a finite set of rules, accounting all possible situations that can occur. But when it comes to solving wicked problems, that is not the case. Various stake holders will have differing views of the solution.  Here it depends on realistic judgment ( subjective)  of the planner and the clientele that leads to the conclusion that a solution can be chosen from a list of potential solutions.

#7 Every wicked problem is essentially unique: This means that despite the similarity between two wicked problems, there can be a additional factor that is over riding. For e,g, the transport problem of city A, while it can be called similar, can't be called the same, with that of the transport problem of city B. Hence the solution that was successfully applied in city A can't be applied in city B. This in a way follows from #1.

#8 Every wicked problem can be considered as a symptom of another problem: A simple definition of  problem can be  "difference between an intended state and current state". The process of solving the problem starts with finding the reason for the difference. Removal of the difference can pose another problem of which the original problem was a symptom. This problem can be considered as a symptom of another higher level problem and so on. For e.g., poverty among citizens can be considered as a symptom of lack of opportunity, failure of government policy, laziness among citizens or whatever causal explanation that is supported by the ideology of the person who is defining the problem.

#8.1 The correct level of solution to a wicked problem is very critical:  Too high a level, we end up taking a general problem that is difficult to solve and too low a level, can introduce un intended consequence.

#9 The causes of a wicked problem can be explained in  numerous ways: How the planner or the analyst's perceives the world (world view) is the strongest factor in explaining a discrepancy and hence the solution in resolving a wicked problem. And here the explanation doesn't strictly follow the 'scientific way' of problem definition. For e.g. crime in the streets, can be explained by not enough police, by too many criminals, by inadequate laws, too many police, cultural deprivation, deficient opportunity, too many weapons etc. Each of these offer a direction in attacking crime in the streets and there is no rule or procedure to determine the correct explanation.

#10 The Planner has no right to be wrong: A scientist can formulate a hypothesis that can be proven wrong and no one blames the scientist for being wrong. But for planners of wicked problems, there is no such immunity, they are expected to get the solution right in the first and only attempt. 

0-0-0-0

The planner of wicked problems is also expected to consider the social context. Society is evolving into a more heterogeneous body. And this evolution leads to different expectations as to what should constitute a solution. And more importantly, (for the planner to consider), the opinions of the individual groups have the risk of turning the solution into zero sum game.

For example, some 50 years ago, setting up a thermal electric power plant would have been a very easy from the perspective of getting approval. But today, the numerous stake holders need to be considered, the impact and benefits of the solution ( setting up the power plant) explained to them, environmental impact has to be considered and so many other factors that would have been irrelevant ( 50 years ago) need to be considered. 

Environmental impact itself can be a very dicey area considering the general awareness of the public and how the scope of 'environmental impact of setting up a thermal power plant' is defined. All this makes the job of a planner, who has set out to help increase power generation, more difficult.

0-0-0-0

Note to the reader

• Though the paper talks about wicked problems from the context of social planning, any problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize, can be termed wicked. 
• The term "wicked" is used to denote resistance to resolution, rather than evil.
• This paper was published in 1973. This paper introduced a new categorization of problem and helped to identify such problems. 
• The paper doesn't help find a solution to the 'wicked problems'. Careful reading of the paper rules out the possibility of a generalized solution existing for a wicked problem. 
• Though 40 years old, this paper still provides valuable insights into the major problems that face our society.
• This concept is also important for Software Professionals because certain class of projects can be classified as 'wicked problems'. More of this aspect in a separate post.

Reference
* Rittel, Horst and Webber Melvin. "Dilemmas in a General Theory of Planning." Policy Sciences, 1973: 155-169.

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

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