Tag Archives: Speed

  • -

Lean thinking and speed of Boeing 737 Final Assembly

Tags : 

How long does it take to do the final assembly of a Boeing 737 and does Lean thinking matter? Final assembly includes wings, tail, wheels, engines, interiors, wiring, cockpit controls, and flight systems.

The Boeing 737 is assembled in one plant in Renton, Washington near Seattle. Since implementing Lean thinking and continuous improvement, monthly output of 737s from Boeing’s Renton plant has tripled:
1999  11
2005  21
2014  42
2017  47
2018  52

As of April 2015, the two 737 production lines produce 42 planes per month or 2 planes per day. It takes 9 days from the time an empty shell arrives at the factory until a completed plane roles out the door ready to fly to the paint shop.

Interested in learning how to use lean thinking to speed up your projects? Innovel offers Certified Scrum Master® and Lean and Agile for Managers courses to show you how to speed up your IT, Marketing, and Development projects.

Watch a timelapse of a Boeing 737 being assembled.

  • -

How can a CEO make software development teams deliver more features, faster?

Tags : 

I recently provided some free advice on Linkedin about software development. A manager had recently implemented Scrum to improve their development process.

While things are better, the CEO, who doesn’t really care about what methods they use, was not satisfied. He wants more features, faster. In this organization they have a lot of legacy code, so implementing new features is slowed by the complexity of the code base.

The CEO wants a solution that will speed up development. The CEO has proposed taking the best developers from every team and putting them on one team where they will create designs and prototypes of the new features that will be implemented by the teams.

The CEO thinks this approach will speed things up. If we assume the teams in place today are competent, the CEO’s proposed approach could really damage the delivery organization’s effectiveness, morale and really slow things down. I hear this kind of thing regularly, so here is how I think about this problem.

Update: I received feedback from a reader that I should explain why the CEO’s proposal will not work. I skipped this explanation because it will take more time and take away from the point of the article. The situation is similar to a person who doesn’t understand cars trying to fix one. They can spend lots of money replacing car parts and never fix the problem.

Here is my analysis of the risks of the CEO’s proposal. Feel free to skip this specific analysis if you want focus on the solution

In this specific case the solution proposed by the CEO is to take the best developers from the current teams to create a new “super” team. The “super” team’s mandate is to create designs and prototypes for the other teams to implement. So the “super” team won’t actually deliver new features customers can use. Every design decision the “super” team makes now needs to be conveyed to the other teams. This “super team” idea increases communication overhead, slows delivery of new features, takes the most productive developers and stops them from delivering features. The “super team” also breaks the currently functioning teams by removing their best developers, making the teams less productive. The intellectual capacity of the team members is wasted because now they only follow the “super” team’s orders (designs, prototypes, etc). This reduced autonomy reduces intellectual capacity of the organization and decreases morale. The staff on the “super team” are also likely to be frustrated, since they are no longer delivering valuable software features, and the work they enjoy the most will be done by others. The people on the “super team” have little experience working together so they will be slow as they figure out how to work together and become a team. The “super team” will spend most of their time communicating instead of coding. The “super team” will likely suffer from departures as the “best” developers, increasingly frustrated with the lack of programming and increased communication overhead look for other jobs. The CEO thinks his proposal will create a team of heroes that will speed up the process. However the solution actually increases communication overhead, increases length of feedback loops (features working or not), slows down the teams, decreases morale, increases waste and creates frustration. Given the information we have today, that the main problem is a legacy code base that is hard to work with (not staff competency), the “super team” solution does not address the core problem.

The organization has a certain speed at which it can produce new things, and the CEO wants the organization to produce faster. Well, every CEO wants that, so nothing new here. The solution proposed by the CEO will not speed up delivery of features, it will slow down the system. The only way the CEO will get an organization that delivers faster is if he pays very close attention to HOW the company builds products, specifically how work flows starting with a new feature request to completed features in production. One can’t fix a system without first understanding how the system works. By paying attention to how work is done, the CEO and every manager can then lead the organization by asking for regular improvements in the process. There are many thinking tools from Lean, the Theory of Constraints, etc. that can help management and teams find problems and solutions.

Getting features out faster is usually the second thing to worry about. Most software that is built is never used. This has been shown in study after study for more than a decade. The only way the CEO will get more value delivered from the organization is to pay close attention to what is being built and ensuring that only the most valuable and important things are being built. This means really understanding what a customer needs AND what they actually use (vs what they think they want). Lean startup provides lots of practical advice to solve this problem of building the right thing.

Since the biggest fastest improvement is achieved by simply not building crap your customers will rarely or never use, I recommend the CEO and the management team together:

1. Change what you are working on to maximize value

Learn: Watch Agile Product Ownership in a nutshell

Read The Lean Startup by Eric Ries (they will enjoy it, written by a tech executive)

Take a 2 day Certified Scrum Product Owner or Lean Startup course from Robin Dymond Contact Us.

Act: Remove as many features as possible from the product backlog (nice to haves, not needed now, not sure who needs it), and harshly re-prioritize the rest of the features.

For example one management team I worked with used the following prioritization scheme:

    1. 1. We’ll go out of business if we don’t have [Feature]
    1. 2. It will cost us lots of money but we won’t go out of business if we don’t have [Feature]
    1. 3. Everything else
    With this re-prioritization the management team discovered that they could get all the 1 and 50% of the 2 priority features done by the deadline. These priorities cut the delivery time by 50% and ensured that the fraud detection system for a major U.S. bank would not hold up a very large re-platforming program. The rest of the 2 priority features were mitigated with manual processes and delivered after the re-platforming.

Apply and Improve: Implement Lean Startup thinking to product feature discovery, prioritization and product feature validation.

2. Change how you organize work to maximize learning, collaboration, and effectiveness of the organization

Managers and leaders:
Learn: Read and study about Lean, Theory of Constraints (TOC), Scrum Velocity
Take a 2 day Lean and Agile for Managers course on these topics from Robin Dymond Contact Us.
Apply: Value stream mapping and Lean tools, TOC.
Hire a Lean Agile consultant to help management and the organization transition to Agile, Lean and TOC management principles and practices. Innovel consultants specialize in this area. Contact Us.
Improve: Measure your starting baseline, including value stream, bottle necks, information silos and velocity. Incrementally improve the value stream, remove bottlenecks, remove silos, and improve flow.

3. Change how you practice design, coding, and testing to improve quality and speed

Learn: Take hands on training in Agile engineering practices and Agile testing.
Apply: Hire a technical consultant to help teams apply Agile engineering and Agile testing practices in their day to day work. Innovel consultants specialize in this area. Contact Us.
Allow time for new practices to be learned and mastered.
Improve: Measure baselines for unit and functional automated test coverage, and code quality. Invest in improving these metrics over time.

Teams working with Legacy code and using Agile face specific challenges. Team members and managers should:
Learn: Read the PDF Working Effectively With Legacy Code and then read the book Working Effectively with Legacy Code
Read about “Technical Debt.”
Apply: Measure baseline technical debt in your system, long term and short term debt. Develop a strategy for paying down technical debt.
Improve: Implement the technical debt strategy together with teams and management and actively manage technical debt.

Metaphor for management: “Does shoving more paper into a printer make it print faster or make things worse?”

smoking printer

Happy New Year!!

  • -

How Healthcare.gov could have saved billions of dollars and been delivered in 1/2 the time.

Tags : 

By September 2014 spending on the 15 state health insurance exchanges and healthcare.gov will climb to over $8 Billion dollars*. This huge expenditure for health insurance shopping sites could have been avoided if the federal and state governments had mandated and followed modern software development practices.


$1 Billon USD. We’ll need eight for healthcare shopping sites.

How did the governments, on something as high profile as healthcare reform, decide to use a risky 40 year old process to manage the delivery of the health insurance exchanges?

Comparisons were made between healthcare.gov and amazon.com, yet the way in which these two websites are developed could not be more different. Healthcare.gov used the phased or waterfall approach with 55 different contractors responsible for different aspects, and no one responsible for delivering finished product. Amazon.com uses Scrum, an Agile approach that emphasizes small cross functional teams who deliver working tested features every 2 weeks.

To understand how a website like healthcare.gov could have been delivered using the Amazon.com approach, I created a short illustrated video. This video demonstrates, in a simple way, how to deliver a site like a health insurance exchange using a fraction of the budget in about half the time. These techniques are very similar to how companies like Spotify, Google, Square, Valve, Salesforce, Amazon and many others manage getting software development done.

Got a few minutes to save billions of dollars on software development?

I hope you like this talk, please subscribe on youtube if you are interested in future videos. If you are looking for in person training for yourself or help for your organization, please contact me:

https://www.innovel.net or http://www.scrumtraining.com

Robin Dymond, CST

*Health and Human Services data

*Report by Jay Angoff on Health Exchange enrollment costs per state

  • -

How Spotify Works. Agility with 1 product and 1200 people

Tags : 

Scaling Agile at Spotify. What True Organizational Agility Can Look Like.

Henrik Kniberg and Spotify released an illustrated video on how Spotify is Scaling Scrum and Agile from a 1 team startup to a 1200 person powerhouse of the online music industry. Spotify is a disruptive force in the music industry, forcing record companies, radio stations, and artists to rethink their business models. Spotify is also an Agile company from the ground up. Spotify got its start using Scrum with one team, so there has been no “Agile Transformation” for the company. Instead the company faced the problem of how to maintain the Agility they had with one team while growing quickly.

The video describes their team structure, the organizational structures that span multiple teams, and the key principles that guide their decision making. I think it is fantastic that Spotify was willing to open the Kimono and show the world how they work, and that Henrik, as their Organizational Coach was able to present it is such a compelling visual way.

This is the cutting edge of organizational agility. For most companies, this kind of organizational model is a fantasy, it is so far removed from their current organization’s structure. If I were a music company executive, I would be scared as hell. Instead, I look forward to continuing to help companies achieve their own improvements for Agility in their own business context.

Part 1 of How Spotify’s Engineering Culture Works

  • -

The Agile Hardware Design Mindset.

Tags : 

Moving to Agile development in hardware is more about mindset than it is about technological limitations. Let’s consider some of the limitations that are often used to resist Agile hardware development, and show how these limitations are more to do with thinking then with technology.

PCB board design and layout.

We can’t do Agile because we need to complete the full board design before sending the design for PCB fabrication and population of parts. Manufacturing is costly and takes a lot of time, so we want to minimize these costs.

Let’s examine each of these points:

Myth: Manufacturing a PCB takes a lot of time.

Facts: The last 30 years of continuous high speed innovation in PC motherboards and mobile phones has driven the PCB manufacturing business to be very quick and responsive. A five minute search for fast turnaround PCB manufacturers revealed many companies that can turn an 8 layer PCB in 24 hours. With overnight shipping, you can have your PCB in 2 days. If you plan ahead with the manufacturer to get parts ordered so it can be populated, this can be done at the same time.

Myth: Manufacturing a PCB is costly.

Facts: The costs for quick turn around PCBs are trivial when compared to the cost of an engineer waiting for hardware. You can calculate costs from a variety of quick turn manufacturers at http://www.ladyada.net/library/pcb/costcalc.html For a 3″x5″ PCB the highest cost for a 2 day turn around was $215, shipping included. For comparison, that average loaded cost of an engineer to their employer is (salary, benefits, office, etc.) is $80-200 per hour. An engineer who spends one day waiting for hardware is far more expensive then the fastest most expensive quick turn PCB manufacturer.

Myth: We need to complete the full design.

Facts: A well designed PCB is modular, with modules for CPU, memory, I/O, RF, etc. Each module is designed as a unit, with interfaces to other modules, just like software. Therefore we can design a module, or part of a module, and that completed design can be treated as a testable deliverable. For example, the CPU and the memory could be designed and shipped as a populated PCB ready for developers to start using. The developers can start to use that platform for coding while the hardware designers work on the next module. The hardware designers will need to implement some features, like a JTAG or USB port and terminate some pins so developers can use the PCB, but that is a small price to pay in exchange for getting hardware into the hands of the software developers.

Deploying iterative and Incremental hardware development.

If we change how we think of hardware from being a single physical device that has to be designed, to a set of functional modules that are deployed as hardware, then we can map the manufacturing process of PCBs to the deployment of code into production. If we can deploy functional modules into a physical device (PCB+parts) in a few days, then we can deliver hardware functionality using an iterative and incremental approach. For example we could deploy a PCB with a basic input output (I/O) circuit that meets our simplest design criteria. This circuit would be deployed into hardware and then could be used by developers for coding and testers. If it is determined from programming and testing that the simple I/O design needs changes, a revision of the I/O could be completed to make the desired improvements. This ensures that the designers are delivering a design that meets the needs of the developers and testers. Once the developers and testers were satisfied, the I/O could be evaluated by the customer to gain their feedback and ensure it meets their needs.

Iterative and Incremental firmware with the hardware.

If hardware is thought of as deployed functional modules, then firmware is the glue that enables these modules to provide customer value. Firmware engineers have numerous well understood options for software development when there is no hardware. Software simulators, emulators, evaluation boards, and FPGAs all provide different options. With every design there are business priorities and technical risks. Based on these risks and priorities the developers need to figure out how to slice the design into components of firmware and hardware that will deliver the most business value and risk reduction with each iteration. For example if I/O is risky then the hardware and firmware developers should figure out how to build, code and test the I/O module before the CPU module. For example this could be accomplished using an I/O PCB that interfaces to a CPU evaluation board.

Using business value to drive product design.

We are faced with the continual expansion of software into the hardware space. Shrinking device sizes, massive gate arrays, generic open source platforms like Arduino, and smart phones all are changing the hardware development game. However software will always need something to run on, and as more devices connect to the internet, the importance of real world interfaces will continue to expand. Great hardware developers like Hewlett and Packard always emphasized getting out of the lab and meeting your customers. As hardware is increasingly used to wire up the connected world, it is more important than ever that hardware designers find ways to quickly respond to the changing needs of their customers. Agile principles and values provide good ideas to help you get there… just replace the word software with firmware or hardware :).

PCB Art by Artist Steven Rodrig
Artwork “Post Apocalyptic Data Hunter: RONIX” by Steven Rodig at PCBCreations.com

  • 1

Wall Street Journal? New York Times? Why is Lean and Agile not a story?

Tags : 

Over the last 2 years we’ve seen some pretty hard times in economies in Europe and especially the USA. Financial services and lending business were in an state of near collapse. With each day companies were announcing job cuts. Job losses in the US are higher than they have been in 30 years. Now that the economy has stopped shrinking, and markets are starting to improve, companies are facing a much more difficult business situation. Stock prices and profits have recovered in some sectors, however most companies face slow growth, and systemic changes in their marketplaces. The US consumer has lost a substantial amount of net worth. That group is not coming roaring back to consume like they have in the past. Many of the businesses that cut staff will not be hiring them back, either because they don’t need the capacity, are doing something different, or are out of business.

Many State and local governments are facing heavy shortfalls in revenue. One important reason for declining tax revenue is property taxes. Property taxes are hard to collect when the property is in foreclosure. Commercial properties are also strapped as their clients break leases or only make limited payments. These losses often result in commercial property owners going out of business. The commercial property failures significantly lag consumer mortgage foreclosures, since commercial properties are not affected until their clients start going out of business. Booming government deficits, high unemployment, slow growth, and increased competition in a global marketplace.

As bad as the economy is now, I am sure it is not as bad as Japan’s collapsed economy just after World War Two. That is when Toyota decided to enter the automotive business. 60 years later Toyota leads the industry by most benchmarks, and are more profitable then the next 4 automotive companies combined. During this recession GM and Chrysler collapsed, and all three big auto companies required billions of taxpayer dollars just to survive as much smaller companies. At the same time Toyota took thousands of idled workers and launched retraining programs so they would be ready for the next generation of manufacturing, new assembly systems, and upcoming products.

The great recession of 2008/9 was bad for airlines, many shrank 10 to 15% and some went bankrupt. During this same recession Southwest Airlines managed to grow by 1%, while paying its pilots more than any other US Carrier. Southwest has been profitable for 36 years straight.

There is a major story that is being completely overlooked by the American Media. That story is how some companies have found a way to gain not one or two years of competitive advantage, but 10-20 years competitive advantage. How some companies consistently innovate and thrive, while others consistently fail to meet the expectations of their customers, employees, investors, and the public. These under-performing companies may have survived the recession, however unlike GM and the banks, there is no bailout coming from cash strapped governments to save them.

What do successful companies like Toyota and Southwest airlines do differently? Can they provide a road map for other organizations? What stopped GM from changing and how to recognize those patterns in other companies?

The New York Times and Wall Street Journal are missing the boat for their readers. There is an important story that European and American business leaders are largely clueless on. I know because of the conversations I have with their VPs, managers and staff. The executives running those companies have a fiduciary duty to get up to speed and start to redesign their organizations so that their companies stop surviving and start thriving.


  • -

Scrum adoption and comments on Martin Fowler’s Scrum post

Tags : 

Martin Fowler recently posted the blog entry “Flaccid Scrum”. Martin makes some good points on Scrum and its adoption without the corresponding agile engineering practices. The observations from his colleagues are common, as teams that are new to Scrum and Agile techniques are learning a new way of working. Scrum implementations lend themselves to adoption of Agile engineering practices. The messy code problem is not a result of Scrum, it is Scrum that has brought visibility to low quality code. Having to put code into production early and often forces teams to recognize defects that otherwise would remain hidden for months in a waterfall process.

Semantic diffusion – Martin’s term for the observation that definitions become diffused over time is an interesting idea. In doing Agile adoption at a major Financial organization we called this “death by a thousand copies.” Someone would have a practices based definition of what Scrum was and then share it with other people, with no references back to the underlying principles. They would modify practices to suit their environment, and those practices would become the defacto “Scrum” for that group. Why does does this occur? We found it was because people did not understand the basic fundamental principles of “why” certain practices are put in place. In the market we see many “ScrumBut” implementations of Scrum, where the basic principles and practices of Scrum are are known and understood but not followed. This phenomena is not just a Scrum problem, Object Oriented development and adoption of Lean principles in manufacturing (outside of Toyota) have also been poorly implemented at various organizations. Each implementation however poorly done, gave some benefit to the organization, often a short term benefit. For example car manufacturers like GM learned how to lower inventory and remove waste from their manufacturing plants.

The time tested way to deal with semantic diffusion, death by a thousand copies, and poor quality code, is to implement two foundational values: respect for people and continuous improvement. Respect for people in Scrum is articulated in ideas such as self organizing teams, pull, and commitment based planning. In Lean it is exemplified in the authority that any worker can and should “stop the line” to address defects and implement solutions that eliminate the root cause of the defect. There are many other examples of respect for people. At Toyota employees are expected to continually improve the process, and if it eliminates the job they were doing the company will find another place they can continue to make improvements. In August 2008 Toyota closed two truck plants in the US but did not do any layoffs, instead putting 4500 employees into a massive training program. This security empowers people to implement improvements knowing they do not need to “protect” their current job on the assembly line. Compare this to the Financial organization that employs talented software engineers to implement repetitive tedious manual production release processes instead of empowering these people to build standardized automated processes. Those same engineers have no interest nor are they asked to implement these automated systems because it would threaten the existence of their jobs and their manager’s jobs.

Continuous improvement, also called Kaizen by the Japanese, is the daily work of finding and implementing improvements to the process. In software the process is how to go from an idea to working testing software in production. Those improvements should result in ever faster translation of ideas into software with less effort and less cost. In North America we are obsessed with Goals and Objectives. However what happens if our goal is to never be satisfied with: the current process of delivering value, the quality, and the cost? How do you achieve perfection in the delivery of software for your customers? How do you do that in the shortest cycle possible?

Scrum does not tell software developers to use test driven development, continuous integration, pairing, or automated testing. Scrum was created that way on purpose. Once you start using Scrum, implementing these practices should be part of the continuous improvement cycle. Learn Scrum, learn XP, learn Lean, learn Theory of constraints, and most importantly, learn what your customers need and strive to fill those needs using these great ideas.

  • 1

Can Scrum Co-Exist with CMMI?

Tags : 

While delivering several CSM classes in Brasil, one question kept emerging about whether Scrum works with CMMI? Specifically, there was one company who was currently transitioning to CMMI Level-2. Now let’s keep in mind that Scrum is already CMMI Level-3 certified, but let’s look at Level-2 just for a quick review.

CMMI Level-2 (Repeatable), it is actually fairly simplistic:

(a) Project status and the delivery of services are visible to management at defined points – for example, at major milestones and at the completion of major tasks.

(b) Basic project management processes are established to track cost, schedule, and functionality. The minimum process discipline is in place to repeat earlier successes on projects with similar applications and scope. There is still a significant risk of exceeding cost and time estimates.

Using the Scrum process provides direct transparency into project progress and status. Transparency hurts sometimes, but Scrum definitely meets that requirement and makes delivery of potentially shippable product visible to management, other project stakeholders, and most importantly to the Team.

So does Scrum satisfy basic project management processes – let’s see?
Cost tracking – with Scrum the customer directly knows who is working on the project and where their money is being spent. This is much more so with Scrum, rather that traditional waterfall, because the customer can actually see who is getting the work done, not just a print-out of billable hours on a time report where it is extremely unclear who is even working on the project.

Schedule and functionality – the customer and the Team regularly re-visit and discuss the schedule at the beginning and end of every sprint. The customer understands what functionality will be delivered based on the commitment the team makes during Sprint Planning and the Release Plan that also gets discussed every sprint. There is continuous planning while using Scrum, not event-based planning as with waterfall; therefore, another CMMI Level-2 requirement is met.

As for the last Level-2 statement – “There is still a significant risk of exceeding cost and time estimates,” this statement is only true when teams or organizations practice Scrum poorly. Scrum is a highly disciplined process and risk gets introduced when it is implemented incorrectly.

So, can Scrum and CMMI Level-2 organizations co-exist – yes they can. The goals of Level-2 are good goals for an organization. These are good practices without saying that they are Level-2 requirements. It makes good business sense to track cost, schedule, and functionality Scrum certainly says that you should track those items.

Where organizations go wrong is that they apply CMMI along the same lines of a waterfall delivery process. They fail to take the Scrum process and map all the principles and practices of Scrum back to the CMMI goals. Organizations also go too deep into the tactics of how teams and individuals should adhere to CMMI. Instead, they should create a framework in which teams can operate that directly coincide with Scrum.

For others implementing CMMI, just remember that starting with the Scrum process itself is usually a good place to begin.

  • 1

Earned Value Measurement – the useless metric for Agile

Tags : 

Earned Value Measurement, for those unfamiliar, is a misnamed metric that is common in more sophisticated waterfall or phased project management. It actually has nothing to do with anything earned. EVM is a measure of how close you are to some pre-defined schedule and pre-defined budget. In essence it is a tracking metric, that when you are 100% on schedule and on budget, you “meet” the standard. Any deviation and you drop below the standard.

In Agile, we start from the assumption that we cannot predict the future. While we know generally how much time scope and budget we have, we know that it is waste to spend large amounts of time and resources building predictive plans. We always flex on scope, and we inspect and adapt to the learning of the team, customer, and business environment. Agile methods can adapt because of the delivery of working product into production, early, often, and throughout the project. This has many virtues – it allows real customer feedback, it validates or invalidates business/investment decisions, it shows strengths and weaknesses of approach, and it provides real learning opportunities for the team, customer and business. Waterfall methods steer like a dragster, and EVM was a tool to tell you how far you had deviated from the initial direction you pointed the vehicle. Agile methods are like driving a car, you look out the window and adjust your course accordingly. If you were to drive from NY to Florida, would you plan every turn before you leave, and how long you would take? Would a tool like EVM, knowing how “off” you were from your initial plan be useful to your trip? Wait! We can’t stop for coffee, our trip EVM meter will show we are deviating from our plan!

Agile methods deliver product to the business and a return on investment early, often, and throughout the project. This means that it is now possible to measure ACTUAL market acceptance and ACTUAL ROI. We are not building bridges or roads where the capital cost outlay is amortized over 20 years. Using EVM does not add value to the project, and does not increase understanding or visibility. Agile and Lean methods emphasize regular demonstrations of actual progress, and regular releases into production. This is what managers need to look at. EVM is built on estimates that are wildly inaccurate because of the uncertainty built into any complex endeavor where the customer doesn’t know what they want until they go on a learning journey with the team, and the business context is continually changing. I urge everyone in the traditional EVM community to just drop EVM, and focus on how you can help customer measure actual, real business value with every release. This is where new ideas for measuring rapid market feedback, capabilities delivered, and how these can drive learning in the organization. I would also ask that EVM practitioners learn something new, and stop trying to shoehorn irrelevant yet burdensome ideas into a completely new way of working.

For more detailed thoughts on what to measure in Agile, I would invite you to read a paper published by Deborah Hartmann and myself at Agile 2006 on Agile Metrics and Diagnostics, you can find it in our Articles section.

  • -

Starting to go Agile? Start with these steps!

Tags : 

1. I would like to understand Agile methods, where can I go and what should I read?

    I recommend reading the first 165 pages of Manager’s guide to Agile and Iterative development. This book provides an understanding of the various flavors of Agile, but also an understanding of why these methods are more effective at delivering projects.

    A classic overview on Agile is Martin Fowler’s The New Methodology. Fowler is an expert on software development practices and patterns.

    The most popular Agile method is Scrum, it is a project management framework that can be used in both IT and non-IT projects. I recommend taking an Agile Project Management course or the Certified Scrum Master course, it will provide an understanding of how to implement Scrum on a project, and the differences between Agile and waterfall methods. Our web site Scrum Training lists public classes we are offering across the country.

2. I understand that Agile is a very different way of working from our current waterfall environment. What are the training options for my company?

    Training is key to success with Agile and Lean work styles. We recommend to all our clients a training plan that includes training for all levels in the organization.

    1. Team members: Introduction to Lean and Agile training (1-2 days) for new teams or team members who will be working on an Agile project.
    2. PMs and Team Leads: Agile Project Management or Certified Scrum Master training for Agile project leaders and key stakeholders
    3. Customers, Sponsors: Product Owner Training for customers, sponsors and key business stakeholders
    4. Directors, Functional managers and Program managers who will manage multiple Agile projects: Lean and Agile Management training.
    For staff in process definition roles we also recommend:

    1. Process engineers and managers building Lean processes: Introduction to Lean training.
    2. Process engineers and managers leading process improvement projects: Lean Belt Certification
    This is baseline training. In addition some excellent training courses that drive improvement in productivity are:

    1. The Secrets of Agile teamwork
    2. Agile User Stories, Estimation, and Planning
    3. Kaizen and KaiKaKu – Lean event facilitation

    Innovel can provide all of these training services through our senior training/consulting staff and relationships with experts in the field.

3. How should Agile methods could be prescribed for new projects in my organization that want to go Agile? What projects should we start with?

    There is no quick answer for this topic, it is best served by a management consulting engagement where we can work through the unique issues in your corporate environment and develop a strategy that best works for your business. Innovel’s staff have helped a Fortune 200 financial services company transition over 50% of a $1 Billion IT portfolio to Lean and Agile. This includes very complex projects with multiple teams on shore and off shore, to defect and enhancement projects that with 1 team serviced customer changes on multiple systems. Other considerations include how can we maintain regulatory compliance? What about Sarbanes-Oxley and Agile?

4. How about Lean and Six Sigma? How do they fit?

    Lean, Six Sigma, and Agile are related. Agile is project centric principles and practices, Lean and Six Sigma are process and organization centric. We recommend adopting Lean at the same time as Agile to avoid local optimization at just the project level and improve organizational effectiveness. We do not recommend Six Sigma in the early stages because it is designed for repeatable manufacturing-like processes as opposed to dynamic product development systems. Six sigma can be used after Lean tools have been applied to production and operational processes.

Please reach out to us if you have any questions or require any additional information on Lean and Agile. We passionately believe in these methods and would be excited to help you and your colleagues discover Lean and Agile.