Showing posts from May, 2010

Lean Thinking 5 (Five) Principles-Pull Products

Principal Four (4)
Pull Products
Lean thinking allows customers to ‘pull’ products and services. A fundamental principle of Lean is that flow should be ‘pulled’ from customer demand (customer first). Unless a downstream process requires it, no work is done: this is the idea of a pull system. The product is not ‘pushed’ from production like traditional systems. Lean Thinking advocates this principle; do not produce a product unless it is demanded by the customer. Production is delayed till there is demand to point out what the business/customer wants.

Lean Thinking 5 (Five) Principles-Creating Steps Flow

Principal Three (3)
Makes Value-Creating Steps Flow
Flow is the step-by-step flow of tasks which move along the value streams with no wastage or defects. Flow is a key factor in eliminating waste. The idea of flow is fundamental to Lean (Agile) production. Waste is a hindrance which stops the value chain from moving forward. A perfect value-stream should be one which does not hamper the manufacturing process. All the steps from the design to the launch of the product should be coordinated. This synchronization would help to reduce wastage and improve efficiency. Again, customer satisfaction is the main consideration to make the value flow. It is important to consider the customer and or business demands and the time of the demands needed to become a successful IT project.

Values Stream Mapping Examples

Value Stream Mapping
Value Stream Mapping is drawing the value stream of the product or process; it is similar to process mapping. It is a tool to look at how value flows into and through a process to the customer, and how information flows facilitate the work flow. Apart from capturing this value flow, it is also used to capture process data on work-in-progress, processing time, processing unit, idle time, setup time, etc. It is also known as information and material flow mapping. Value Stream Mapping helps to locate the wastes in the value chain. After the waste is identified, it is removed. A current state map can be created when the waste is identified. This leads to the creation of a future state map with a plan to eliminate the waste. The next logical step is to implement the plan. This means the value stream is restructured. This is a basic step towards Lean conversion. It is an effective method to develop an environment with a reduction in waste. It helps to streamline the wor…

Lean Thinking 5 (Five) Principles-Value Stream

Principal Two (2)
Identifies Value Stream
Value stream is the stream or flow of all the processes which include steps from the development of the design to the launch and order to the delivery of a specific product or service. It is the sequence of steps that a company performs to satisfy their customers’ needs. A value stream consists of product and service flows and information flows. It includes both value added and non-value added activities. Agile teams are excellent at streamlining non-value added (paperwork, meetings) activities and supplementing them with value added activities (development/testing time)Agile is the the way to go in a time constricted, resource constricted, financial constricted environments.

Lean Thinking 5 (Five) Principles-Value

Principal One (1)
Lean thinking is another way to improve processes. Lean thinking helps organizations to become continually efficient by increasing value, profits and minimizing waste. Although, Lean Thinking is generally applied to the production process to improve efficiency, it can be applied to all the facets (Development, QA, Business Analyst, and Project Management) in the organization.
The first step towards Lean is identifying things that create value. Value is determined by the customers. It is about customer demands and what the customers are able and willing to pay for. Lean uses methods like focus groups, surveys and other methods to find out the preferences of the customers regarding the existing products and services. This is so important today because with the rapid changes involved in application development we sometimes forget who this is for CUSTOMER FIRST mentality must be present in your companies thinking now and for the future.

IT Projects and the Theory of Constraints (TOC)-Shortcomings

The absence of constraints could help any organization in any business they decide to focus on earn unlimited profits. According to TOC (Theory of Constraints), the conventional methods of cost accounting, such as efficiency and utilization are faulty. This would mean that the organization which has applied/ or would apply the TOC (Theory of Constraints) would replace the traditional methods with throughput, inventory and operating expense. It is easy to calculate the metrics of these methods. However, it becomes difficult when reality logic trees, undesirable effects, evaporating clouds and future reality trees need to be calculated during the problem solving stage. This becomes increasingly difficult for laymen like the front-line managers and supervisors to calculate. Methodologies are constantly changing and evolving as the IT industry matures. Agile I believe right now is the perfect fit for fast changing, ever evolving IT enterprises.

IT Projects and the Theory of Constraints (TOC)-Benefits

I will end this discussion with the benefits and shortcomings of Theory of Constraints (TOC)

1. It increases the ability of the organization to accomplish its goals. It also increases the net profits and the returns on investments (ROI) for an organization by applying cost reduction techniques like elimination of unnecessary work or non-value added activities.
2. It lessens the confusion in the organization quality team communications.
3. It reduces the production lead time (agile 2 week iterations). Lead time is the gap between order and its delivery.
4. It reduces cycle time of the IT product. Cycle time is the time gap between the start of the work and its completion.
5. It lessens the work-in-process in a development process and/or the finished application in a network.
6. It reduces labor-time per piece of code.
7. It gives capacity to the staff to analyze and resolve routine conflicts.

IT Projects and the Theory of Constraints (TOC)-Step Eight

Wastage of manpower is a matter of concern. Agile uses collaboration teams so manpower becomes less of a concern. Agile IT generalists are motivated by updated their current skill sets so they are interchangeable between team members. To avoid this kind of wastage depends on the recruitment process, styles of management, attrition rate, low motivation by the higher authority and not using the employees’ ability to the fullest potential. (Again agile uses collaboration in its team structures) People’s abilities should be utilized fully in terms of mental and creative level, their skills and experience you must foster in a collaborative learning environment. The main goal of Lean is elimination of waste. Waste can be eliminated by identifying it and eradicating all non-value-added activities. Non-value adding activities eat up time, money and resources. If you implement an agile lean environment you will have happier, smarter, better trained and utilized employee throughout the proje…

IT Projects and the Theory of Constraints (TOC)-Step Seven

Sorry for the slight digression from the discussion of lean but I was performing a test with SlideShare and my SlideShare presentation portal. I know that’s it’s a little out there when we are discussing Lean. Now back to Lean, with any movement in terms of people or machinery that adds zero value to the product is wastage in terms of motion. The examples of motion waste include time wasted in hunting for tools, product handling, and arrangement of products, walking and loading. Some of these things are hard to associate with Agile but I will say that assigning people to work in the same area or environment is totally Agile in its thinking. The reasons for motion wastage include poor infrastructure, incompetent labor, weak processing and constant changes in agenda setting. Adopting Lean methodology helps as it exposes fruitless efforts and motions executed by the employees.

User Stories for Agile Project Management

IT Projects and the Theory of Constraints (TOC)-Step Six

Waiting means idle time. It comprises waiting for code from up-stream operations, waiting for automation tools (if you are using them), resources and directions from higher authority. Now if you have ever worked in a QA team you know about waiting. In the older methodologies like waterfall you spent a lot of time spinning your wheels till the software was delivered. With Agile you work side by side with the developers so there is truly NO downtime. As a team you help design the tests for the application or the part of the code that is being delivered in this iteration. You will then prepare tests for the next piece of code that will be delivered in the next sprint. The time wasted in measuring and procuring information also makes up for idle time and is considered a waste. Idle time is the one when no value is added. In fact, waiting for manpower/labor is a matter of greater concern than the usage of computers or machinery.

IT Projects and the Theory of Constraints (TOC)-Step Five

Although transportation is an important aspect of the manufacturing process, I can’t really use it for this discussion on IT projects yet it is a non-value added activity as it adds to costs but not to the value of the project. Costs like manpower and systems needed to track the material include the additional money spent on any transportation. Keeping the testing as well as the live environment as close as possible (apples to apples) still remains key, as well as having QA access to the development environment so the cross functional team aspect of the methodology (Agile) remains intact. Environments need to be accessible 100% during the busiest times as well as after the 9-5 work schedule. With the advent of 24/7 accessibility to the environments all upgrades, patches or fixes must be done on an off hours schedule so not interfere with resources during the 2 week sprints. You will probably have to hash this out at the beginning of the project so infrastructure is on the same page…

IT Projects and the Theory of Constraints (TOC)-Step Four

Processing paperwork is a waste which adds zero value to the product or service from the customer’s perspective. It comprises the project with spare copies of paperwork and other surplus processing for unforeseen problems which might occur in the future. Agile is keen on shrinking the amount of documentation that is normally produced on projects. That does not mean that you don’t document things, quite the contrary you start to document ONLY items that you need, not every single last word or meeting from the project team. This is always one of the toughest parts or Agile, knowing when to stop the documentation because the business thinks that when you stop detailing every little discussion that you will miss something pertinent to the project. And Agile sometimes has the reputation of being like extreme programming “run and gun". Wasted time and resources also occurs in the form of acceleration of processes to meet targets. Creating more meetings and or more documentation wil…

IT Projects and the Theory of Constraints (TOC)-Step Three

All the other activities should be made subordinate to the constraint. The individual workings of the other processes in the system should be aligned in such a way that they do not affect the outcome of the constraint. This is for the benefit of the system. The speed of the other processes is matched to the speed of the constraint. Yes but as always there is a flip side of subordination, and that is that the system should not be pushed to do more than the capacity of the constraint. (Can you hear the development teams, QA teams screaming?) This would lead to excess work-in-process, extended lead times, or even affect delivery times of the application. And if we are trying to run this project in the Agile methodology then we will have to reduce the effects of the constraint, and then we must change how we manage the constraint going forward. We must make the value stream flow and combine the Lean “Just in Time Scheduling” (JIT) model to keep the project flowing, on time and successfu…

IT Projects and the Theory of Constraints (TOC)-Step Two

Once the constraint is identified, the very next step is to take measures to improve upon it. The result or results of the constraint is the limiting factor of the entire process; therefore it should be ensured that the constraint is performing that function that it uniquely does to its maximum capacity. Now you will need a complete strategy or correcting method that will be developed to exploit the constraint. The constraint might be resources, teams, etc but as the project manager you can’t give up because constraints shift during projects to other teams or resources and will throughout the project life-cycle. Remember to exploit the constraint we must squeeze as much out of the constraint (employee time/full-time from part-time) as you can, that is the meaning of “exploiting”. Observation will and can be (idle time, machine or environment breakdown) pivotal in the management of the constraint.

IT Projects and the Theory of Constraints (TOC)-Step One

The focus of the theory of constraints (TOC) is to bring an improvement in the system. The theory of constraints is always relevant while developing IT projects because date, budget and resource constraints are always issues on all IT projects. The theory of constraints is a concept developed by Dr. Eliyahu M. Goldratt. It is a concept that focuses on identifying and easing the constraint that restricts an organization’s ability to attain a certain targeted level.

The TOC approach can be implemented in five steps: STEP ONE

1. Identifying the Constraint
A system is like a chain and one weak link in the chain obstructs the performance. The chain which delivers the worst performance is believed to possess the constraint. A study of the unwanted symptoms that a system or process is suffering from can lead to the identification of the constraint or constraints.

Lean Applications in Product Development- Back to the Development Source Engineering

Now the last but not least discussion in the thread is with all the high tech development, the developers spend their time in their cubicles. However, the set-up should be such that the developer remains close to the physical product. Kelly Johnson, the famous head of Lockheed's legendary Skunk Works once quoted, “An engineer (developer) should never be more than a stone’s throw away from the physical product.” The developer should spend time at testing as well as developing thus ONE of the core processes of Agile, cross functional teams. This is one principle that forms the core of a product development process and can be easily applied in a Lean (Agile) set-up to minimize wastage and to improve customer and business satisfaction.

Lean Applications in Product Development- Standardization for Flexibility

Standardization is important as it helps to eliminate waste out of the product development process. If the processes and the design standards are standardized, there is scope for fixing individual responsibility and flexible product development capacities throughout the development team. The standards created are also important as far as downstream lean development capabilities are concerned. There is a great article by Susan Cramm from the Harvard Business Review on what does the future hold for IT, in the article she speaks about “internal roles will shift from being technology providers to technology brokers" and "roles remaining in the IT function will organize around build and run." This to me speaks volumes about the Agile methodology and the practice of it in IT projects. The “build and run” synopsis for me just screams Agile’s iterative development style of 2 week deployments of development, testing then deployment of usable code. I think in the future speed w…

Lean Applications in Product Development-A Synchronized Process

For concurrent engineering to be effective, it is important that each ensuing function should utilize the established information from the preceding function as and when it becomes available. The development teams should, therefore, work with the part of the design data (requirements) that is unlikely to change and try to check wastage and save time. Each function’s processes should be designed in a manner which move forward and simultaneously build established data around as and when it becomes available. This practice is referred to as simultaneous execution. You can now see how lean is creating an offshoot of a pro-lean subculture, and it is emerging from within the Agile project and development community. Classic Agile Methodology bases a large part of its development using concurrent engineering, building and testing at the same time in small teams or concurrently developing usable code with every iteration. Iterations are built on 2 week sprints so after each sprint you have …

Lean Applications in Product Development-A Continuous Improvement Process

Learning and measuring for improvements should be a part of all the processes in any organization. The performance goals that need to be set for an organization should be finely detailed and should be accomplished during the project. Lessons should always be learned from the goals accomplished for the project and ALL employees should always upgrade their knowledge base. This can happened during the project which happens a lot because of resource constraints, and time lines. I have worked on many a project that we have to learn as a team new technology, code or an application that can assist us in the successful completion of the project. In fact, all the errors should be chronicled so that they are not repeated in the future, I have created a lessons learned document that I have the various teams complete after the project has had a successful launch. A problem solving session can also be held to extract multiple solutions and focus should be on the root cause and the countermeasur…

Lean Applications in Product Development- Front-Loaded Process

A definition of Front Loaded Process will bring back I believe the most important thing that you can learn about Lean in IT projects, they define it as “Front-loaded is including robust planning and design early in a project's lifecycle (i.e., the front end of a project), at a time when the ability to influence changes in design is relatively high and the cost to make those changes is relatively low”. How important is it to have the business define the “PROJECT” and the team “business analysts” document (requirements) in a precise fashion. The definition and requirements gathering must be detailed sound and through because it is a vital (if not the most vital) part of any successful IT project. If the definition is not clear and the requirements are not documented in a through fashion then adding lean will do nothing to accomplish success. The engineering process that is applied should be firm and the problem solving techniques along with cross-departmental participation will m…