Agile Method madness

The war of words between some agile advocates and waterfall traditionalists shows no signs of ceasing, but growing numbers of project leaders and teams are choosing not to choose sides. Instead, they recognize value in both approaches, and they apply their techniques based on the needs and realities of each project.

There’s a war or words raging. On one side are ardent agilists, who advocate managing projects using methods such as Scrum and XP. On the other side are traditionalists, who prefer waterfall methods. Just look at the venom in these headlines and stinging excerpts from recent articles on project management and product development:

“The Agile Method and Other Fairy Tales”

“Rigid vs. Agile”

“Waterfall methods are notorious for leading one to believe projects are on schedule when, in fact, they are not.”

“Agile proponents are the leaders of a dysfunctional industry.”

What are these opposing approaches to managing projects? It’s a bit hard to pin down — and that’s part of the confusion — but here’s a broad distinction. “Traditional” methods are planning-driven — they place a high value on early and thorough planning before executing the plan. Agile methods emphasize flexibility and incrementalism over detailed planning through a series of short (typically 2-4 week) “plan-do” iterations rather than engaging in advance planning. 

An example may help. Let’s say that you expect to take a month-long vacation in Hawaii. If you use a traditional planning-driven approach, months before the trip you’ll study guidebooks, research event listings, plan your daily itinerary, and procure advance tickets to key activities. When you arrive in Hawaii at the start of your vacation, everything is all laid out, including a pair of hard-to-get tickets to the Jimmy Buffet reunion concert that sold out months in advance. 

Alternatively, you could manage this trip as an agile project using one-week iterations. Before leaving for the islands, you’ll make a high-level wish list of activities that sound interesting, but you won’t spend much time on detailed pre-planning. At the beginning of every week on Hawaii you’ll figure out what activities you will do that week based on your wish list, the weather forecast, and the people and places you discovered last week. This allows you to be flexible and explore your emerging interests, such as accepting a spontaneous invitation to attend an authentic family luau with a local resident that you met the first week.

Although this is an exaggerated example, it illustrates some of the pros and cons of each approach. The traditional approach, with its emphasis on advance planning, is efficient when you have relatively clear knowledge about the future course the project is likely to take, the risk or cost of having to redo things is low, or advance preparation confers important benefits such as managing long lead time orders. You plan once and then do (perhaps with minor modifications). This allows you take advantage of opportunities like attending that once-in-a-lifetime Jimmy Buffet concert under the palm trees. 

In contrast, the agile approach is most powerful when you can’t clearly see the future of key elements of the project. Frequent short iterations of planning and then doing add flexibility and reduce risk. This flexibility means that you’d have a great time going to the local luau during your vacation, an event you never could have pre-planned because the opportunity didn’t come up until you met a local during the trip.  Unfortunately you’d miss seeing the Jimmy Buffett concert because it was sold out months before you started any of your weekly iterations.

Which approach is best? It depends on the type of project you’re doing — the length of its planning horizon, the cost of rework, the value of flexibility for the project, and perhaps even the culture of the organization performing the project.  

However, we don’t have to pick sides, either agile or traditional. Sometimes the most powerful solution is  to combine elements from both approaches, choosing detailed planning for stable parts of the project and shallow, iterative planning for other parts that are likely to change. This is currently called a hybrid approach, but the idea goes back at least 30 years to project management author F.L. Harrison, who called it “Rolling Wave Planning.”)

A Plea for Peace

It’s clear that both agile and traditional approaches have valuable elements. Either can also be abused, causing a project to fail rather than helping it succeed.

Allow me get on my soapbox for a moment. Stop the caricatures and call a truce to this unnecessary war. Draw the best from both perspectives. The bottom line is that techniques from both approaches should be part of your practitioner toolkit, and you must develop the judgment and skill to be able to apply the best technique to a particular project situation.


 I'm definitely in favor of using "a method" and adhering to a process that makes sense and provide the necessary foundation for project success. And I couldn't agree more that "soft skills" need to be combined with "hard skills" for a project to be successful.
It's a challenge to discuss "method" in the absence of a domain and context. In the Enterprise IT domain, there is an ITIL paradigm that spells out a framework for processes and adherence to those process. When Amy uses the word " slavish adherence" she's using a loaded word in the absence of a domain and context.

You'd better be doing " slavish adherence" if you're the SOX compliance officer at a publicly traded firm, or the DCAA compliance officer in the federal contracts office of a large construction company.
In other domains, or even other contexts in a specific domain the "rules" for what is allowable, what is acceptable, and what is desirable, vary widely.

So when Amy says, "Now I manage projects using the orientation I taught - which is 90% showing up to be present to the situation as it is and 10% applying the tools (rigid or not) appropriately. " Does "manage" mean project that deliver products to customers in the field, or manage projects that deliver services to constituents, or what exactly.

There is a huge variety of "methods" used to successfully manage a project. Some can have broad flexibility of exactly how the management processes are applied, some have very little flexibility is that process. If we were to visit our local PMI monthly meeting and randomly stand at the bar and ask "how to you succesfully manage your project," we'd get everyone from people like me subject to DFARS  to methods I've heard Amy speak about "which is 90% showing up to be present to the situation as it is and 10% applying the tools (rigid or not) appropriately." In our domain it's very little about working on "showing up" that is the price of admission. It's about 100% compliance with the corporate and government processes  and agency procurement process.

So in the end it's tough to pin down what are the core principles and practices for project success without first establishing the domain, context, and culture.

So again, it's difficult to assess the effectiveness of an experience outside the specific domain and context without more information. Now add to that thread Enterprise IT. ITIL, regulatory based - health care for example, retail, general commercial, hard goods, products - Boeing has different PM management processes than would Target on how they plan develop and deploy time keeping or procurement of raw goods using ERP.

To give you some sample to look at please look at this ad for Boeing, but this is representative of many of the programs we work. In this domain, "ruthless adherence to method" is a critical success factor. This is an extreme example and likely outside the experience of many here, but it is represenattive of a domain where "method" and "process" are critical.
In other domains, method and process may not be a critical factor. The discussion of "high method" versus "no method" is completely dependent on the domain. It can not stand alone. Alone the discussion of method has no actionable outcome or purpose

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