Agile Pushing/Pulling a study

Introducing Agile methods to a team in an organization deeply rooted in waterfall ways is tough, especially when the culture is risk-averse and well-established. But you can be a catalyst for change and help your team learn to be more agile by following three simple practices.

About my learning, I learned Agile methods early on from some of the industry’s best, practioners, Trainers.  For more than 15 years, I was part of an organizations that embraced Agile values, was customer-connected, and focused on continuous learning. And then as life progressed I changed jobs. More importantly, I changed organizations.

The culture shock was intense as I went from the world I knew of embracing change, to a culture that spoke of learning and growth, but was weighted down in waterfall ways and cemented in processes averse to change. Instead of co-creating value with the customer and validating along the way, I found myself among a sea of BUFD (“Big Up-Front Design”), and the customer at the tail-end of the process.

I had my work cut out for me. I could be a fish out of water, or I could teach others to swim. I chose the latter. Otherwise, it was not just me at stake, the organization would sink in today’s highly competitive world.

But I was intimately familiar with organizational change gone bad, and I experienced many situations first-hand where the change agent fails and loses in the end. Luckily, with the guidance of a mentor, I learned that I needed to be a change leader, not a change agent, and that starting small, and building momentum is the key to success.

Early on, I it was like pushing rocks up hill. I did brown bags, I gave out copies of my book, Getting Results the Agile Way, and tried to preach the gospel of the Agile ways, but it fell on deaf ears, or, in other cases, the student wasn’t ready. But the irony was that the organizational pain was exactly the impetus that would justify going Agile. There was a lack of clarity in customer demand. People were over-worked and felt under-appreciated. Change was a constant on a daily basis, and yet people could not respond quickly enough or use the change to their advantage.

And then, I changed my approach. Rather than “push” Agile, I inspired people to “pull” it. I did so in three specific ways:

1) Ask better questions

2) Lead by example and

3) Reinforce positive behaviors.

Together, these simple practices inspired others to learn and adopt more Agile approaches in their thinking and in their actions, and this built momentum over time.

 Ask Better Questions

I started asking simple questions in the hall, to key people. The most important question I started with was: “What were our 3 Wins from last month?”

I would tee it up by saying, “We put in a lot of hours last month. Looking back, what are the actual wins we have under our belt?” It was a simple way to get leaders reflecting on how well all the hours we throw at work are leading to significant outcomes … or not.

Looking back was now the key to looking forward. I would then ask the following question: “What are our 3 Wins we want to achieve for this month?”

Soon, people started thinking in terms of outcomes for the month. It was no longer good enough to throw a bunch of time at things and accomplish a bunch of tasks, and yet have no simple stories of success, or customer victories to show for it.

I didn’t stop there though. To reinforce the idea of chunking up things and thinking in terms of incremental value, I asked simple questions in team meetings and in my 1:1 with my manager:

What were your 3 Wins for last week?

What are your 3 Wins for this week?

What are our 3 Wins we want to achieve for this year?

Questions served as the prompts to start driving better behavior, and getting people to get curious and seek better ways to find their 3 Wins. 

 Lead by Example

People learn from others and they model the behaviors they see — especially if the behaviors they see lead to results they like. The three most important behaviors I set an example for were:

Visualize the workflow on the wall

Daily standup meeting with the team

Pairing up with others to create better, faster work products

To visualize the workflow on the wall, I created a simple Kanban for the team, where people could see our backlog of work items, the current work in progress, and work we completed. I kept it very simple and used only three stages: To Do, Doing, and Done. On Mondays, in our team standup, I went around the team, and asked each person to identify their 3 Wins they wanted to achieve, write them down on a sticky, and add them to the Doing column. Instantly, everybody had a chance to show and share their focus for the week.

For daily standups, I asked the members of my immediate project team to attend a simple “Ten at Ten” meeting. The idea was to spend 10 minutes at 10:00 AM each day to help us stay in sync, deal with any changes or urgent issues, and unblock people on the team. We’d simply go around the team and state three things:

What did you get done yesterday?

What are you working on today?

Where do you need help?

This helped the team stay connected, fluid, and always making progress with focus and momentum.

On pairing, a lot of people were resistant at first, but once they experienced it in action, they latched on to it. They liked the idea that rather than get stuck on something, two people could put their heads together and blast through something faster that might otherwise be death by a 1,000 paper cuts. To get started, if we had to produce a document, I would simply open the document, and start asking questions to frame out of the key outline of the document, and start plugging in key information. Once the skeleton for the document was in good shape, we would then split off, finish things off, then pair back up to do a live review. It was fast, effective and people got to learn from each other at a faster pace than they otherwise could.

 Reinforce Positive Behaviors

This is perhaps the most important way to help a non-Agile team adopt Agile practices. People like to succeed. Catch them doing something right, and call them on it. Use learning opportunities and leadership moments to coach people, not critique them.

The most important person I focused on first was my manager, since he set the tone for others on the team. For example, his strength was focusing on tasks, but not focusing on wins. It was his growth opportunity. When he would identify his 3 Wins he wanted to achieve for the team for the week, I would be sure to tell him how it helped us focus, prioritize and know what was valued. This helped reinforce the behavior by letting him know how it shapes the team’s impact for the week.

So the point is whenever it feels like resistance, figure out the causes for concern or reasons for resistance, and use them as feedback to tune and prune the approach. It's always amazing how one approach can be so much more effective than another, and yet they both attempt to achieve the same goal. And, in my experience, adding "the fun factor" always helps.

As Gandhi said, “Be the change you wish to see in the world.” The key is to start with your immediate world and to bring others with you. The key to bringing others with you is to prompt them with the right questions, lead by example, and reinforce positive behaviors. As a project leader, skilled in the art and science of Agile practices, the world needs you now more than ever. Your success, and the success for those around you, will depend on how well you lift them and help them learn the agile way.

Along these lines, experience tells me three keys to successful change that show up time and again are:

1. Change the approach - I've seen how changing styles or approaches radically helps success

2. Change the time frame - Often, it's too much, too fast. Little wins with momentum works better.

3. Change the people - Sometimes the chemistry is off. Try another change leader. Sponsorship can make a big deal here.

The trick is to become a master of the process and evangelize to terms / jargon, but good ole organization, leadership and communications goes a long way.

And remember, sometimes a great change has the right intent, but unless somebody helps map it to specific benefits by the people impacted, it will meet a ton or resistance. Also, I find people in general sign up for change, when it's not pushed down their throat.

There is a great deal of opportunity to expand Agile into other arenas. In fact, aside from "Agile for Life", my favorite place to apply Agile approaches is to learning and education. One of the ways we improved our success is by doing an "exploration" phase, before we start "execution." During exploration, we collect user stories and system stories, and then prioritize the set with customers to validate the impact. By the time we start executing, we have a great view of what a Minimum Credible Release (MCR) or MVP (Minimum Viable Product) would be. Sure, things change during the development cycle, but this vision of the MCR keeps us grounded.

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 .