Agile and Lean Project Management

Agile and Lean Principles

My belief is to succeed at the largest scale, Agile software development should use Lean manufacturing principles.  The command-and-control hierarchical organization of large companies is rapidly giving way to a more biological metaphor, one in which a corporate nervous system senses important signals from the market and supply chain and rapidly reacts. At the largest scale, this trend is being driven by principles of Lean manufacturing, which envisions the enterprise as a massive event-driven system, waiting to create products when customer orders arrive instead of building products in advance and holding them in inventory.

Software development has been similarly transformed by Agile development methods. In this arena, the command-and-control ethos is represented by the Waterfall development methodology, which follows a seemingly reasonable pattern of gathering requirements, designing a product, and building and testing. The problem is that requirements are almost always wrong. The Waterfall method does not allow for mid-course corrections, and the beginning-to-end cycle may span a year or even many years.

Agile posits a huge payoff for being highly suspicious of software requirements. In Agile methods, instead of building the whole product, you build the smallest possible useful part and give it to users, who tell you what is right and what is wrong. Agile development is an evolutionary conversation in which incremental steps of two to four weeks lead to feedback that allows requirements to be tested and adjusted. In addition, some functionality is available much sooner.

Quality also increases in Agile projects because using a working system exposes defects right away instead of leaving them to a final testing phase. Many other aspects of Agile are beneficial but beyond the scope of this discussion.

Agile's popularity has led to a problem: How do you apply it at scale? How can a large project run using Agile methods? One team working on one project in an Agile way is not hard to envision. But what about running 10 or 20 teams, each working on part of a product? How does the list for each iteration get sorted out and synchronized? How does the result of each iteration become integrated into the larger whole?

I've been discussing this topic for a few months with Ryan Martens, CTO of Rally Software, a leading vendor of software and training services to support adoption of Agile development. In addition, I saw a fascinating presentation about tracking Agile projects at the New York CTO Club last week in which Bruce Eckfeldt, the founder of Cyrus Innovation, an Agile training company, detailed various methods of tracking progress of Agile projects.

What surprises me is that most advanced practitioners of Agile now use more vocabulary from Lean manufacturing than from Agile. In essence, as a practical matter, good ideas from Agile are being absorbed into a new approach to software development that is Leaner than anything else. Someone else can name this phenomenon, but Lean and Agile are merging.

The fundamental recommendations of Agile methods are focused on creating a rapid feedback loop between the users supplying the requirements and the technologists transforming them into a solution. Agile methods also suggest a variety of engineering practices that increase the quality and stability of code.

Agile has much less to say about how to connect the work of many different teams, and that's where Lean has a huge impact. In a Lean manufacturing system, the work is broken into a set of value streams triggered by demand signals. The output of one value stream leads to others. Value streams may be executed sequentially or in parallel as needed. Eventually, everything is combined into the product. The suppliers for materials needed are alerted through a system of just-in-time replenishment of parts and components called Kanban.

Large organizations that are using Agile are applying a value stream approach in which various development teams are organized in sequential and parallel streams of work so that at the end of each iteration, you get a new version of the product. Sometimes different rhythms of iterations occur, with some work taking place in faster increments followed by the integration of everything every fourth or fifth iteration.

The Lean concept of Kaizen also has a strong influence on the way Agile is being practiced, filling a gap relating to continuous improvement. The evolution of Agile is primarily focused on evolving the product toward a better fit with requirements. In Agile, both the product and the requirements are refined as more is known through experience. Kaizen, a continuous improvement method used in Lean, focuses on the development process itself. When Kaizen is practiced in an Agile project, the participants not only suggest ways to improve the fit between the product and the requirements but also offer ways to improve the process being used, something usually not emphasized in Agile methods.

"The power of Agile is that it's self-adaptive, It teaches software teams how to deliver value to customers and how to improve themselves using techniques like Kaizen, allowing them to deal with unique and changing constraints and environmental factors."

In practice, Agile seems to be changing for the better by adopting Lean thinking in a large way. Customers get to market 50% faster and are 25% more productive when they employ a hybrid of Lean and Agile development methods. Given the way that Agile fits in to the Lean framework, it wouldn't surprise me if before too long Agile is considered a branch of Lean practice tailored for the software industry.

Let’s start from Agile architecture. Most of my discussions surrounding agile architecture have been focused on exploring how modularity helps increase architectural agility. I claim that modularity is a required (and to this point, missing) aspect of agile architecture. The basis for this claim follows:

·         Architecture is design, but not all design is architecture.

·         Design is architecture if the design is architecturally significant. That is, if it’s hard to change.

·         The goal of architecture is to eliminate the impact and cost of change.

·         The way to eliminate the impact and cost of change is through flexibility.

With flexibility comes complexity. We must therefore strive to increase flexibility while taming complexity.

Modularity helps us identify where we need flexibility by understanding the joints of the system where flexibility is necessary. Without modularity, we can’t identify the joints so it’s more difficult to understand where we need the flexibility. My posts titled Modularity & Architecture and Modularity by Example show visual examples comparing designs that are isolated and insulated to designs that span the joints of a system. I’ve also devoted extensive discussion to these ideas in a number of other posts, which I summarize in my Agile Architecture Presentation post.

Lean Principles:  Recently, I’ve been spending more time exploring lean software development principles and their relationship to agile architecture, and the best place to start when examining lean is with the Poppendiecks. I’m fascinated by the synergy that exists between the lean principles and agile architecture. In fact, when reading the second chapter of their book, “Implementing Lean Software Development: From Concept to Cash“, I was pleasantly surprised by an interesting discovery.

It seems that a study of software development practices by Harvard Business School professor Alan MacCormack revealed four  fundamental practices that lead to successful software development. These include releasing early, continuous integration, experience and instinct, and a modular architecture. So it seems I’m not alone in feeling modularity is a critical component of agile architecture. But the thrust of the discussion comes later on in Chapter Two, when speaking of deferring commitment.

Deferring Commitments, Reversibility, and Eliminating Architecture. Deferring commitment focuses on two fundamental factors - reversibility and irreversibility. In general, reversible decisions are those that can be changed while irreversible decisions are those that cannot be changed. We should strive to make irreversible decisions at the last responsible moment. For it is at this moment when we possess the most knowledge that will allow us to choose the most viable option. But are also advised that First and foremost, we should try to make most decisions reversible, so they can be made and then easily changed. For me, this captures the essence of eliminating architecture. If we are able to take a seemingly architecturally significant challenge and make it reversible, then we have effectively minimized the impact and cost of change to a point where change is no longer architecturally significant. Going forward, I intend to more fully explore additional synergies between lean software development principles and agile architecture.

Lean Principle First Deliver Fast : Deliver Fast.  In a way, that’s a funny principle to have.  I would have thought that’s stating the blinking obvious!  But the reality is that it isn’t.  All too often in software development, things seem to take ages.

It is common for people to think too deeply about future requirements that may or may not ever arise.

It is common for people to be blocked – maybe requiring help or information from others – and not to react to that problem with the kind of urgency it deserves.

It is common to over-engineer solutions, both in terms of the software architecture, and also the business requirements.

Why build a simple solution and get it to market quickly to be enhanced incrementally based on real customer feedback when you can build one gigantic monolithic beast of a system and build it all before you launch anything for your users? (for those that can’t detect sarcasm, that was meant to be ironic btw!).

When a team is held up waiting for someone, others in the team could potentially pick up the task everyone is waiting for and get it done, even if it’s not normally their role.  It’s important in agile teams to establish a good team spirit. It shouldn’t be the case that everyone sticks rigidly to their job specs.  ”That’s not my job” really isn’t a phrase I’d ever like to hear in an agile team.  If the team needs something done in order to achieve their objectives, the whole team should feel willing and able to help each other out, even if it sometimes means deviating from their usual specialty.

Speed to market is undoubtedly a competitive advantage.  There is considerable evidence that companies who gain ‘first mover advantage’ go on to be the most successful companies in their chosen sphere.  Companies can copy, and sometimes even come along later and do things better, but often it is the first to establish itself that wins the day and becomes the long term leader in its field.

Another advantage of delivering fast is that, if there is as little time as possible between the Product Owner stating the requirements and the team delivering the product, there is little chance of the requirements changing.  Less time minimizes the chances of changes in the market, changes in people, or even simply a change of mind.

So what is required to go faster?

Have the Right People.  As with any methodology, it’s important to have the right people.  Lean thinking in the manufacturing industry originally changed the way companies think about their people.  Instead of factory lines where the principle is to standardize everything to the extent that all people are performing small routine tasks and are essentially interchangeable, they moved towards the idea of having ‘thinking people’.  People who are able to think for themselves, solve problems, be proactive, be flexible, take appropriate actions, make decisions.  As per Lean Principle #2 – Create Knowledge.

Keep It Simple.  Another way to go faster, as I eluded to earlier, is to keep things simple.  Keep the requirements simple.  Keep the technical solution simple.  Find the easiest way to meet the users’ goals.  Don’t over-engineer.  Don’t spend too long considering future requirements that may never materialise.  Get something simple to market and build on it based on real customer feedback.

Work as a Team.  Really as a team, helping each other to make sure that the team achieves it’s objectives, whatever it takes.  Be flexible in the tasks you are willing to pick up.  When you commit to something, do everything in your power to deliver on it.

Eliminate Waste.  The Second  principle of Lean is to eliminate waste.  Sometimes it’s easier said than done, but this is clearly another way to deliver faster.

Build Quality In.  in order to go faster, you really need to build quality in.  A team that suffers from lots of bug fixing, or lots of breakages as changing one area affects another, or lots of post-delivery remediation work, can never go as fast as a team that is delivering good quality in the first place.

The third principle of lean software development is Create Knowledge. This one seems a bit strange to me, as it almost seems obvious and common sense. But then I guess we all know that common sense isn’t that common! Thinking about the fact that the origins of Lean are in manufacturing, where the traditional approach is to simplify and standardize everything to the point where no knowledge is required, like on a factory line, then I guess it’s clear why this principle was originally such a different way of thinking.

In software development, we all know that knowledge is paramount. We’ve all had situations where there’s only one developer that can work on something, at least productively, or even at all. Nothing beats the knowledge that’s created when someone actually writes the code. Although I’m not particularly an advocate of Pair Programming, this is a specific agile practice from XP (Extreme Programming) that helps to ensure that the inherent knowledge that comes from writing the code is held by at least two people, rather than one.

So, if knowledge is important, and helps the longer term productivity and flexibility of the team, you need to take some specific actions in the short term and put some specific things in place to ensure that you create it. Exactly what you do, as always, depends on your particular situation. Here are some things you could do on your projects to help create knowledge:

·         Pair Programming

·         Code reviews

·         Documentation

·         Wiki – to let the knowledge base build up incrementally

·         Thoroughly commented code

·         Knowledge sharing sessions

·         Training

Use tools, such as tinyPM, to manage requirements/User Stories

I’m sure there are lots more. But these things are often not given the priority they really deserve. What do you do – proactively – to create knowledge in your teams?

Defer Commitment.:  I’m not sure I really like the name of this one. It could easily be misunderstood. It doesn’t mean you should put off committing to anything indefinitely, or defer all decisions – that would obviously be a very bad idea.  What it does mean, is decide as late as possible, particularly for decisions that are irreversible, or at least will be impractical to reverse. Timebox critical decisions for the latest point they can be made without causing problems.

Obviously it is also important not too leave decisions too late. This can delay the team and make projects difficult. But, the later you can safely leave critical decisions, the more information you will have available to make the right decision when the time comes.

Deferring irreversible decisions means you keep your options open for as long as possible. By the time the decision needs to be made, there is every chance that you will know more about which of those options is the best route to take. It also gives you time to potentially explore the different options in more depth and experiment, helping to come to the right conclusion.

In areas of complexity or uncertainty, where things are very likely to change, this is especially important. In areas like this, as well as deciding as late as possible, you should also try to architect your solution to be flexible, in order to make fewer decisions impractical to reverse. Another example of deciding as late as possible in agile development methods is Sprint Planning, or iteration planning. In agile, you decide what features to include in each iteration and analyze them just in time for them to be developed. Keeping decisions about features and the development of those features close together helps to ensure that the right product is delivered, because it leaves less room for change.

In more traditional project management methods, in between the specification and any particular features being developed, there is a much longer period of time when change can occur. Changes in requirements, changes to the underlying system, changes in technologies, changes in people (either the product owner or the development team), changes in direction, or of course changes in the market.

Deciding too early, you run the very likely risk that something significant will have changed, meaning your end product might meet the spec, but it might still be the wrong product! This is one reason why so many projects fail. So, try (within reason) to architect your solution so that fewer commitments are irreversible. And defer commitment on irreversible decisions to the latest point possible.

Agile and Lean Principles

My belief is to succeed at the largest scale, Agile software development should use Lean manufacturing principles.  The command-and-control hierarchical organization of large companies is rapidly giving way to a more biological metaphor, one in which a corporate nervous system senses important signals from the market and supply chain and rapidly reacts. At the largest scale, this trend is being driven by principles of Lean manufacturing, which envisions the enterprise as a massive event-driven system, waiting to create products when customer orders arrive instead of building products in advance and holding them in inventory.

Software development has been similarly transformed by Agile development methods. In this arena, the command-and-control ethos is represented by the Waterfall development methodology, which follows a seemingly reasonable pattern of gathering requirements, designing a product, and building and testing. The problem is that requirements are almost always wrong. The Waterfall method does not allow for mid-course corrections, and the beginning-to-end cycle may span a year or even many years.

Agile posits a huge payoff for being highly suspicious of software requirements. In Agile methods, instead of building the whole product, you build the smallest possible useful part and give it to users, who tell you what is right and what is wrong. Agile development is an evolutionary conversation in which incremental steps of two to four weeks lead to feedback that allows requirements to be tested and adjusted. In addition, some functionality is available much sooner.

Quality also increases in Agile projects because using a working system exposes defects right away instead of leaving them to a final testing phase. Many other aspects of Agile are beneficial but beyond the scope of this discussion.

Agile's popularity has led to a problem: How do you apply it at scale? How can a large project run using Agile methods? One team working on one project in an Agile way is not hard to envision. But what about running 10 or 20 teams, each working on part of a product? How does the list for each iteration get sorted out and synchronized? How does the result of each iteration become integrated into the larger whole?

I've been discussing this topic for a few months with Ryan Martens, CTO of Rally Software, a leading vendor of software and training services to support adoption of Agile development. In addition, I saw a fascinating presentation about tracking Agile projects at the New York CTO Club last week in which Bruce Eckfeldt, the founder of Cyrus Innovation, an Agile training company, detailed various methods of tracking progress of Agile projects.

What surprises me is that most advanced practitioners of Agile now use more vocabulary from Lean manufacturing than from Agile. In essence, as a practical matter, good ideas from Agile are being absorbed into a new approach to software development that is Leaner than anything else. Someone else can name this phenomenon, but Lean and Agile are merging.

The fundamental recommendations of Agile methods are focused on creating a rapid feedback loop between the users supplying the requirements and the technologists transforming them into a solution. Agile methods also suggest a variety of engineering practices that increase the quality and stability of code.

Agile has much less to say about how to connect the work of many different teams, and that's where Lean has a huge impact. In a Lean manufacturing system, the work is broken into a set of value streams triggered by demand signals. The output of one value stream leads to others. Value streams may be executed sequentially or in parallel as needed. Eventually, everything is combined into the product. The suppliers for materials needed are alerted through a system of just-in-time replenishment of parts and components called Kanban.

Large organizations that are using Agile are applying a value stream approach in which various development teams are organized in sequential and parallel streams of work so that at the end of each iteration, you get a new version of the product. Sometimes different rhythms of iterations occur, with some work taking place in faster increments followed by the integration of everything every fourth or fifth iteration.

The Lean concept of Kaizen also has a strong influence on the way Agile is being practiced, filling a gap relating to continuous improvement. The evolution of Agile is primarily focused on evolving the product toward a better fit with requirements. In Agile, both the product and the requirements are refined as more is known through experience. Kaizen, a continuous improvement method used in Lean, focuses on the development process itself. When Kaizen is practiced in an Agile project, the participants not only suggest ways to improve the fit between the product and the requirements but also offer ways to improve the process being used, something usually not emphasized in Agile methods.

"The power of Agile is that it's self-adaptive, It teaches software teams how to deliver value to customers and how to improve themselves using techniques like Kaizen, allowing them to deal with unique and changing constraints and environmental factors."

In practice, Agile seems to be changing for the better by adopting Lean thinking in a large way. Customers get to market 50% faster and are 25% more productive when they employ a hybrid of Lean and Agile development methods. Given the way that Agile fits in to the Lean framework, it wouldn't surprise me if before too long Agile is considered a branch of Lean practice tailored for the software industry.

Let’s start from Agile architecture. Most of my discussions surrounding agile architecture have been focused on exploring how modularity helps increase architectural agility. I claim that modularity is a required (and to this point, missing) aspect of agile architecture. The basis for this claim follows:

·         Architecture is design, but not all design is architecture.

·         Design is architecture if the design is architecturally significant. That is, if it’s hard to change.

·         The goal of architecture is to eliminate the impact and cost of change.

·         The way to eliminate the impact and cost of change is through flexibility.

With flexibility comes complexity. We must therefore strive to increase flexibility while taming complexity.

Modularity helps us identify where we need flexibility by understanding the joints of the system where flexibility is necessary. Without modularity, we can’t identify the joints so it’s more difficult to understand where we need the flexibility. My posts titled Modularity & Architecture and Modularity by Example show visual examples comparing designs that are isolated and insulated to designs that span the joints of a system. I’ve also devoted extensive discussion to these ideas in a number of other posts, which I summarize in my Agile Architecture Presentation post.

Lean Principles:  Recently, I’ve been spending more time exploring lean software development principles and their relationship to agile architecture, and the best place to start when examining lean is with the Poppendiecks. I’m fascinated by the synergy that exists between the lean principles and agile architecture. In fact, when reading the second chapter of their book, “Implementing Lean Software Development: From Concept to Cash“, I was pleasantly surprised by an interesting discovery.

It seems that a study of software development practices by Harvard Business School professor Alan MacCormack revealed four  fundamental practices that lead to successful software development. These include releasing early, continuous integration, experience and instinct, and a modular architecture. So it seems I’m not alone in feeling modularity is a critical component of agile architecture. But the thrust of the discussion comes later on in Chapter Two, when speaking of deferring commitment.

Deferring Commitments, Reversibility, and Eliminating Architecture. Deferring commitment focuses on two fundamental factors - reversibility and irreversibility. In general, reversible decisions are those that can be changed while irreversible decisions are those that cannot be changed. We should strive to make irreversible decisions at the last responsible moment. For it is at this moment when we possess the most knowledge that will allow us to choose the most viable option. But are also advised that First and foremost, we should try to make most decisions reversible, so they can be made and then easily changed. For me, this captures the essence of eliminating architecture. If we are able to take a seemingly architecturally significant challenge and make it reversible, then we have effectively minimized the impact and cost of change to a point where change is no longer architecturally significant. Going forward, I intend to more fully explore additional synergies between lean software development principles and agile architecture.

Lean Principle First Deliver Fast : Deliver Fast.  In a way, that’s a funny principle to have.  I would have thought that’s stating the blinking obvious!  But the reality is that it isn’t.  All too often in software development, things seem to take ages.

It is common for people to think too deeply about future requirements that may or may not ever arise.

It is common for people to be blocked – maybe requiring help or information from others – and not to react to that problem with the kind of urgency it deserves.

It is common to over-engineer solutions, both in terms of the software architecture, and also the business requirements.

Why build a simple solution and get it to market quickly to be enhanced incrementally based on real customer feedback when you can build one gigantic monolithic beast of a system and build it all before you launch anything for your users? (for those that can’t detect sarcasm, that was meant to be ironic btw!).

When a team is held up waiting for someone, others in the team could potentially pick up the task everyone is waiting for and get it done, even if it’s not normally their role.  It’s important in agile teams to establish a good team spirit. It shouldn’t be the case that everyone sticks rigidly to their job specs.  ”That’s not my job” really isn’t a phrase I’d ever like to hear in an agile team.  If the team needs something done in order to achieve their objectives, the whole team should feel willing and able to help each other out, even if it sometimes means deviating from their usual specialty.

Speed to market is undoubtedly a competitive advantage.  There is considerable evidence that companies who gain ‘first mover advantage’ go on to be the most successful companies in their chosen sphere.  Companies can copy, and sometimes even come along later and do things better, but often it is the first to establish itself that wins the day and becomes the long term leader in its field.

Another advantage of delivering fast is that, if there is as little time as possible between the Product Owner stating the requirements and the team delivering the product, there is little chance of the requirements changing.  Less time minimizes the chances of changes in the market, changes in people, or even simply a change of mind.

So what is required to go faster?

Have the Right People.  As with any methodology, it’s important to have the right people.  Lean thinking in the manufacturing industry originally changed the way companies think about their people.  Instead of factory lines where the principle is to standardize everything to the extent that all people are performing small routine tasks and are essentially interchangeable, they moved towards the idea of having ‘thinking people’.  People who are able to think for themselves, solve problems, be proactive, be flexible, take appropriate actions, make decisions.  As per Lean Principle #2 – Create Knowledge.

Keep It Simple.  Another way to go faster, as I eluded to earlier, is to keep things simple.  Keep the requirements simple.  Keep the technical solution simple.  Find the easiest way to meet the users’ goals.  Don’t over-engineer.  Don’t spend too long considering future requirements that may never materialise.  Get something simple to market and build on it based on real customer feedback.

Work as a Team.  Really as a team, helping each other to make sure that the team achieves it’s objectives, whatever it takes.  Be flexible in the tasks you are willing to pick up.  When you commit to something, do everything in your power to deliver on it.

Eliminate Waste.  The Second  principle of Lean is to eliminate waste.  Sometimes it’s easier said than done, but this is clearly another way to deliver faster.

Build Quality In.  in order to go faster, you really need to build quality in.  A team that suffers from lots of bug fixing, or lots of breakages as changing one area affects another, or lots of post-delivery remediation work, can never go as fast as a team that is delivering good quality in the first place.

The third principle of lean software development is Create Knowledge. This one seems a bit strange to me, as it almost seems obvious and common sense. But then I guess we all know that common sense isn’t that common! Thinking about the fact that the origins of Lean are in manufacturing, where the traditional approach is to simplify and standardize everything to the point where no knowledge is required, like on a factory line, then I guess it’s clear why this principle was originally such a different way of thinking.

In software development, we all know that knowledge is paramount. We’ve all had situations where there’s only one developer that can work on something, at least productively, or even at all. Nothing beats the knowledge that’s created when someone actually writes the code. Although I’m not particularly an advocate of Pair Programming, this is a specific agile practice from XP (Extreme Programming) that helps to ensure that the inherent knowledge that comes from writing the code is held by at least two people, rather than one.

So, if knowledge is important, and helps the longer term productivity and flexibility of the team, you need to take some specific actions in the short term and put some specific things in place to ensure that you create it. Exactly what you do, as always, depends on your particular situation. Here are some things you could do on your projects to help create knowledge:

·         Pair Programming

·         Code reviews

·         Documentation

·         Wiki – to let the knowledge base build up incrementally

·         Thoroughly commented code

·         Knowledge sharing sessions

·         Training

Use tools, such as tinyPM, to manage requirements/User Stories

I’m sure there are lots more. But these things are often not given the priority they really deserve. What do you do – proactively – to create knowledge in your teams?

Defer Commitment.:  I’m not sure I really like the name of this one. It could easily be misunderstood. It doesn’t mean you should put off committing to anything indefinitely, or defer all decisions – that would obviously be a very bad idea.  What it does mean, is decide as late as possible, particularly for decisions that are irreversible, or at least will be impractical to reverse. Timebox critical decisions for the latest point they can be made without causing problems.

Obviously it is also important not too leave decisions too late. This can delay the team and make projects difficult. But, the later you can safely leave critical decisions, the more information you will have available to make the right decision when the time comes.

Deferring irreversible decisions means you keep your options open for as long as possible. By the time the decision needs to be made, there is every chance that you will know more about which of those options is the best route to take. It also gives you time to potentially explore the different options in more depth and experiment, helping to come to the right conclusion.

In areas of complexity or uncertainty, where things are very likely to change, this is especially important. In areas like this, as well as deciding as late as possible, you should also try to architect your solution to be flexible, in order to make fewer decisions impractical to reverse. Another example of deciding as late as possible in agile development methods is Sprint Planning, or iteration planning. In agile, you decide what features to include in each iteration and analyze them just in time for them to be developed. Keeping decisions about features and the development of those features close together helps to ensure that the right product is delivered, because it leaves less room for change.

In more traditional project management methods, in between the specification and any particular features being developed, there is a much longer period of time when change can occur. Changes in requirements, changes to the underlying system, changes in technologies, changes in people (either the product owner or the development team), changes in direction, or of course changes in the market.

Deciding too early, you run the very likely risk that something significant will have changed, meaning your end product might meet the spec, but it might still be the wrong product! This is one reason why so many projects fail. So, try (within reason) to architect your solution so that fewer commitments are irreversible. And defer commitment on irreversible decisions to the latest point possible.

Microlearning - new way of learning

Let’s start with basic understanding. Basically, micro-learning describes a method of learning, whereby concepts and ideas are presented (or retrieved) in very small chunks, over very short time-scales, often at the point of need, or at the point of maximum receptiveness.

Depending on frames and domains of reference, micro and macro aspects vary. These are relational concepts. For example, in the context of language learning, one might think of micro aspects in terms of vocabularies, phrases, sentences, and distinguish them from situations and episodes and socio-cultural specifics or complex semantics. In general discourse on learning, one might differentiate between the learning of individuals, group learning or learning of organizations and the learning of generations or societies.

Furthermore, microlearning marks a transition from common models of learning towards micro perspectives on and the significance of micro dimensions in the process of learning. The microlearning approach is an emergent paradigm, so there are no hard definitions or coherent uses of the term yet. However, the growing focus on microlearning activities can be seen by web users' activities on the subject, who tag their corresponding weblog postings and social bookmarks with the term "microlearning"

Some people do talk about sending text (SMS) messages to learners – perhaps a question or a brief statement of fact/opinion. But, unless this is something the learner has asked for, it’s unlikely to make much of a difference, and may even just be ignored.

Micro-learning can be based on any type of media, but the key thing is that the media should be in small chunks. A one hour video, with a piece of useful learning somewhere in the middle can be painfully difficult to use in a micro-learning context. But a pack of videos put together in a Youtube playlist is perfect – as each video is individually addressable, and can be linked to.

Similarly, there’s no point just giving someone a 60 page PDF document. You need to be able to point them to the particular page, or even paragraph, in the content that will help them at their point of need.

Now let’s move to examples & applications. When customers call a bank, they are pleased to receive perfect, courteous service. When customers bring a car in for service, they don't want to be told the job will take two extra days because the mechanic will be in class. They want results now.

Business is about productivity, not learning. The learning challenge is to keep employees productive and learning simultaneously. Micro-learning can be a critical component of the strategy because it satisfies immediate knowledge needs to enable performance. As technologies advance, micro-learning evolves to match the needs and pace of business.

Learning and consumption have several similarities. According to the FDA, the most beneficial eating patterns include eating six small meals through the day when one is truly hungry as opposed to when a clock says it is time to eat. In other words, consume when needed. There is a lot to be said for applying the same strategy to learning as to nutrition. The analogies include:

a) Too much consumption at one time can be painful and stressful, and the value can be lost.

b) It is often wasteful. Investments of time and expense may not satisfy the true need.

c) No one wants to clean up after a big meal. It can be messy and exhausting to redo learning and restore order.

Micro-learning strategies facilitate knowledge acquisition, employee learning and performance support, when and where needed. It is just enough and always available should learners need to partake more as demanded. However, it is just as important to enable employees to learn where they are and to have learning be integrated tightly into their work.

Sometimes this may involve a smartphone, tablet or presentations though an online, corporate intranet. Eventually e-learning may be accessed in a manufacturing plant or hospital by scanning a QR code and reading resulting content on a handheld device. Consider current standby micro-learning examples such as instant messaging, blogging and even the telephone and water cooler. These are now ubiquitous in the workplace. The expertise needed to be tapped belongs to top performers, and their knowledge transfer is not specific to a certain delivery mode.

Since micro is a relative term, let's give it some bounds in reference to what has been common in the learning industry for years. A five-day instructor-led course would not be considered micro-learning, nor would an eight-hour e-learning course. However, each lesson and its assets could be made available for easy reference when demands for performance arise. Recall that first reference to a phone call to the bank. Perhaps the bank representative is referring to information from the latest course about the new mortgage program restrictions to satisfy a customer's call.

Microlearning – Learning, not Training

The learning may occur during the call to satisfy the customer and the employee aspiring to deliver excellent service.

Consider that service in a mobile environment. Now that the housing market is picking up in parts of the country, home shows and conventions are experiencing a comeback. Banks and mortgage companies may be onsite to assist with financing. They must be untethered and ready to support buyers. Perhaps they are equipped with a state-of-the-art tablet with a high-speed network connection. The same scenario can be replayed face-to-face.

Or, consider a chemical manufacturing plant that has just moved, so the location and operation for some equipment is new. Rather than expecting employees to retain everything about the facility from a class conducted a month earlier, engineers can scan a QR code using their smartphones to access documentation for the new equipment, a video of its use and directions for shutdown if necessary. Ideally, all of this would have occurred in the workers' native language.

The learning needed for the representative and the engineers was just enough, and when and where it was needed. In both the public and private sectors, organizations have recognized the value of leveraging learning content in relevant, worker-consumed chunks.

A global engineering company might employ the strategy and realize significant savings by downsizing an expensive help desk which supports employees after the roll-out of new business applications. In a large public school system, employees across the jurisdiction might access bite-sized learning assets relevant to their task at hand, enabling record keeping being flawless in the schools and main offices.

According to Cushing Anderson of market intelligence firm IDC and his 2010 Modality Survey, "Measuring the impact of training on the enterprise is frequently weak. Most are unable to describe the business impact that successfully trained or skilled workers will have on the performance of the related technology." This drives a trend to match more targeted micro-learning investments to specific job needs.

An IDC survey also documented changes in delivery modalities into 2012. The drastic increase in asynchronous e-learning points to the workforce's need to access what they need when they need it.

There are some common issues with micro-learning in an organizational learning strategy.

1. Retention
IDC research and anecdotal data shows that knowledge retention from traditional learning methods is 20 percent at best. Perhaps the right strategy is to assume low retention and focus on leveraging all assets from the classroom as performance support. Current data and folklore indicates 70 percent of learning happens on the job.

2. Performance Support
To match employees' working environment, learning leaders may have to modify classroom development and think ahead to where else content will be accessed and on what device or channel.

3. Collaboration
As recently as 30 years ago, this looked like a tap on the shoulder, but it is powerful, and it has evolved into an electronic action. For synchronous micro-learning, techniques such as instant messaging, social media and email are well understood. However, employees cannot always rely on experts' availability, especially with the global reach of today's organizations. Subject matter experts and mentors may be anywhere. Facilitating a platform on which it is easy to consume and contribute is a solid component of an effective micro-learning strategy.

4. Enablement
Enabling experienced experts to articulate their knowledge and stories is easier than ever. Given available technologies, they can record their actions or their voice to enable those who need to know. A smartphone could equal a movie studio. The value of subject matter experts is not in their knowledge, but in their ability to share that knowledge and expertise, especially as they prepare for retirement or for that next job within the organization or at a new company.

Enabling those who are required to know is the next challenge in a micro-learning strategy. Search, search, search should be the mantra. It does not matter how much valuable content is available for micro-learning if no one can find it. Searching text contained in the content is easy. However, when the asset is a video or an online simulation of a business transaction, searching must be enabled by attaching tags and keywords relevant to the learner and in the learner's specific context and language.

The case has been made for employee-generated content. However, just because experts have something to contribute does not mean they should. Platforms can be governed in such a way that publishing comes after composing, and learning leaders can provide all the tools and methods to make the development and review easier.

5. Prove It
If leaders, experts, mentors and consultants are going to invest their time to share their knowledge to be consumed in bite-size meals, it may behoove learning leaders to ensure team members consume it. Then, assess learning reception and comprehension.

The value of employee learning is measured on the job. Think about the bank representative in those two environments described. The measures of the learning to enable his or her performance could be customer satisfaction as well as new consumer loans from new and existing customers.

Imagine if learning leaders could correlate the data about the consumption of the micro-learning assets to business outcomes. The business case develops itself to continue the efforts. Learning is not an industry where process compliance is externally mandated. It can be policed internally.

Does micro-learning adoption mean that all learning content should be scrapped or converted? No. Innovation is demonstrated by leveraging existing assets while investing in content to satisfy the descriptors.

According to Yvette Cameron, vice president and principal analyst at Constellation Research Inc., managing work is the true focus in the workplace. When recently addressing an audience of human resources professionals, she highlighted the characteristics of effective work management tools.

She also recognized that learning is the stickiest part of the HR sphere of influence and action.

Micro-learning is about employee performance support, but the label is not as important as the effect. Remember, business is all about productivity. It's not about learning. Therefore, the tight integration of learning and business enables a culture to thrive and expect integrated learning in the workplace - just in time and just enough. Size does matter.

Microlearning is best used as a part of a blended learning solution and is suitable for:

ü  Initiation: Activating knowledge before a classroom (or virtual classroom or even and eLearning session)

ü  Windups : Summarizing (after one of those sessions – delivered soon after the session)

ü  Follow-up: Recall (or reactivating knowledge – probably a week or two after the session. This ensures key concepts are revisited and helps in transferring the new knowledge to long term memory – especially for learners who may not get a chance to apply new knowledge immediately after the sessions)

ü  Hammering: Providing application opportunities (through pop quizzes or learning games on mobile)

ü  JIT: Just-in-time search support by letting employees search in company’s knowledge databases (wikis, blogs, forums) using their mobiles

ü  Increasing Reach: By creating microlearning courses compatible with mobile devices, we can bring about a paradigm shift in the way we learn at the workplace

I have tried this at many cooperates for my PMO, Agile & CMM migration classes these techniques are very effective for me. If you have any specific questions please share with me at ravindrapande@mail.com .

Be friend with yourself

“If you make friends with yourself you will never be alone.” ~Maxwell Maltz

In his words - I’ve always been a rebel—independent, and a bit of a loner. I’ve prided myself on self-sufficiency. I like to do things my own way, and I don’t care for unrequested input (to put it

mildly!). I’ve been self-employed since I was 18 in a profession it can be tough to make a living in. In large part, I’ve been successful because of my ability to care for and emotionally support

myself.

For me, this self-love has served my goal of doing what I want to do with my life, regardless of whether we have any support from the outside world or not. Despite all the practice, I don’t fully have this self-love thing down. This is also situational.  It’s an ongoing project, and some days are better than others. On the not-so-fab days, I’ve got some techniques I use to up the ante on feeling great about me.

Make a list of your accomplishments.

I guarantee there have been many. Nobel prize nominations are not required. The fact that

We could even bake amazing pies or are the person your friends always call when they want a sympathetic ear are great examples,  so are getting a degree or knowing how to change your car’s oil. Refer to this list when you are feeling not so special. Soak in all the cool stuff you’ve achieved and remind yourself how awesome you are. Personally, I love the reminder that I was voted “most unique” in high school 6^th standard C. P & Berar High school .

Always learn something new.

You don’t have to become an expert on an entire subject (unless that’s appealing). Learn how to say “have a nice day” in Sanskrit or hit up Wikipedia’s “random article” link until you find something interesting. Pointing our focus toward something outside of ourselves is stimulating; it also expands our world and our perspective. Additionally, learning makes your brain happy.

 Ask your very best friend/partner/favorite family member what they love about you and specifically how you are amazing. (Periodically)

Take note of what they say and refer to it later when you are feeling a bit unloved. While our view of ourselves is of primary importance (it is about self-love, after all), it’s always nice to hear some complimentary words from someone we love whose opinion we respect. Let me be super-clear: I am not talking about the “friend” who is actually a of enemy, or the family member who insists on subtly criticizing your life choices. This question is reserved for one of your very tuned people who happens to feel the very same way toward you.

Put your focus on others with small acts of kindness.

If I’m having a self-critical day, my tendency is to want to turn inward and pay little attention to the outside world (and expend my energy getting down on myself—not very useful). Instead of allowing that, I will make an effort to chat with people I come across and offer a kind word; I’ll be a more considerate driver; I’ll make a point of saying “hi” to people I don’t know.

For me, focusing on others serves as a simple reminder that we are all connected, as well as sending the message to my system that playing the introvert and self-criticizing is not acceptable to me. This is important to understand as wrapping around you or closing your eyes does not make world blind. Like cat drinking milk.

And sometimes, turn inward.

I trust myself enough to know when I just need an hour or two of nothing. No email, internet, or other diversions—just me and a cup of something, hanging out, plotting my future, thinking about what I want, where I’m going, and how I’m going to get there.

For me, this is like hitting a re-set button. It clears my brain of some of the clutter, alleviates some of the negative internal dialogue, and leaves me feeling motivated and renewed.

Mantra jap or Meditation is great. So is a half-hour in clam temple or a coffee shop sans boss and kids. Both can be incredibly fulfilling. Do whatever works for you.

Put on your most-loved music and dance.

Its an incredibly basic concept, but oh so easy, super fun, and all good baby. I defy you to feel bad after your endorphin-pumping, stress-relieving, body-moving, shamelessly personalized dance party for one. Go to some old friends house to surprise them & dug some good thoughts about past.

Practice self-care.

The most effective tool I use to avoid the not-so-great-in-the-self-love-department days is regular self-care. I engage in many small acts of self-care, with occasional larger ones thrown in.

Getting up early enough to enjoy my morning coffee; scheduling myself in a way that doesn’t cause my head to explode when I look at my calendar for the day; making sure my refrigerator is well-stocked so I don’t end up having Maggie / bread and butter for dinner—these details work for me and support me in feeling strong and solid. I simply feel better about myself when my life is running smoothly. And since I’m the one running my life, the responsibility to make it so is mine.

Remember: While we are all connected, and in many ways are the same, you are the only you there is. You are unique, amazing, and special. Revel in it, ‘cause you rock. We all have this pull inside of us: We can either nurture our fears and insecurities, or we can nurture our trust in love, kindness, and acceptance. This is not a new concept.

There is an endless amount of information out there about connecting with your inner self and finding happiness from within.

However, all that information can feel overwhelming and even discouraging. If you’re anything like me, you may find yourself still aching from a broken heart, or beating yourself up for the chocolate-chip cookie you just ate shortly after reading about finding forgiveness, gratitude, and self-love.

What I realized was missing for me in my quest for self-improvement—and what kept pulling me back to my old, familiar negative thinking, feeding the insecure wolf—was faith.

In order to make the meaningful changes that allow us to release the grasp of our fears and limiting thoughts and beliefs, we have to be willing to believe in the positivity—believe that we deserve to stop beating ourselves up and looking for an external solution to “fix” us. It’s not enough to just think it. We have to believe it.

The world we see is a reflection of our inner experience.

When we see love and light, we are connected to love and light inside of us. And conversely, when we see the inadequacies around us, we’ll connect with that inside of ourselves.

Look around you. Where can you find evidence of the light in your life, the light within

you?

This concept was never more evident for me than when I had my daughters yeah twins. Whenever I veer off course—when my old, familiar, fearful thoughts creep up to tell me how I’m not good enough, I don’t have enough, or how everything is going to fall apart—I think about my daughters. When I look at her, I’m able to so clearly see the beauty and the purity of the human soul. Which was result of our upbringing so this is kind of litmus test for me.

He doesn’t have to do anything to prove or earn his lovability; I certainly don’t look at them and think, “if she lost/ put a little weight, I’d love them more,” or “When she meets that educational / financial goal, that’s when I’ll love her.”

These thoughts don’t even cross my mind when I think of him, so why would it seem logical to say them to myself?

We all started out in the same place, with a full capacity for love and loving. We weren’t born into this world with fears of failure or being emotionally walled off. Children know no limitations until we point them out to them.

There was once a time in your life when your dreams knew no limitations, when you were free to take risks, and even if you fell down, you were able to get back up. Now, all the pain of the past can almost be seen as a blessing. It has led me to the most wonderful time in my life where I am not so much hopelessly in love, but I am so fulfilled and content in myself that I have never felt happier.

This positive love that now fills my heart and my world is available to every single one of us.

Opening our hearts and minds to love and positive space is the key to a life of love. Understanding who we are, that we are lovable and worthy of love allows us to love and be loved.

I urge you to learn about yourself—your past, your emotions, your reactions. Honesty is key. You have to face up to who you are, which can be very difficult. Imagine me, a confident, organized, highly functioning executive discovering my life was run on an urge to prove I’m worthy of love. That was a hard one!

But if you can deeply connect with the real you, who wants, needs, and above all deserves to be loved, a freedom lies ahead that is beautiful to behold.

That light is still in you. It doesn’t ever go away, sometimes fear just overshadows it.

Fortunately, fear is a learned response that has built up over time, which means that we can unlearn it! When we allow ourselves to realize that the fear isn’t real, we get to make a different choice. We can choose to find the love instead—to feed the loving wolf. I know that when I look at my son and I see that loving energy, it is my loving energy reflecting back at me.

Take a look around.

Where do you see your loving reflection shining back at you?

What inspires you?

Where can you look for a reminder to stay connected to your belief that you deserve a life of love, and that the love and all possibilities are already inside of you?

How can you stay present and aware of which wolf you are feeding?

(I would strongly suggest jot down these questions &review once a month you will never be alone in life at least you will know where you should go to unwind )

Share your comments to make this better ravindrapande@gmail.com