buy topiramate

Tag Archives: Agile coaching

  • -

How to Avoid Fatal Product Flaws with Agile and Scrum? Lessons from Boeing’s 737 MAX 8 Program

Tags : 

After finishing systems installation, a Boeing 737 is prepared for wing installation at Boeing’s 737 assembly plant in Renton WA.

Why did Boeing’s development of the 737 MAX 8 effectively avoid Agile principles? Agile foundations are part of Boeing’s toolset. Boeing could have maintained a focus on quality and safety for the aircraft’s overall development program, and its key avionics systems, had they been followed.  

Employees of Boeing, and others with an understanding of avionics systems and the business of airplane manufacturing, suggest the recent 737 MAX 8 crashes are rooted in Boeing’s business priorities and design processes for the aircraft. Both have been aimed at avoiding re-certification, re-training costs, and delays for the Boeing 737 Max, an aircraft that differed markedly in aerodynamic and avionic terms from its predecessors.

Agile Foundations at Boeing

The loss of life from recent 737 MAX 8 crashes is incomprehensible.  Concerning and confounding is that the principles we now call Agile were foundational to the success of Boeing’s 777 development program.  From 1990-1995, across a complex international context of 10,000 engineers, Boeing engineering executives promoted such Agile-informed principles as:  

  • quality and/is schedule (quality is a critical ingredient);
  • panic early (fast fail);
  • plan for zero overtime (sustainable pace);
  • weekly design, build, test (DBT) reviews (weekly scrums);
  • make decisions faster (act and learn fast).

With Agile principles, and related quality assurance practices having been deployed with success at Boeing in the early nineties, why was an Agile-underscored focus on quality abandoned during the development of the 737 MAX 8?  In Agile terms, why were extrinsic quality (value in meeting the needs of end-user pilots for trust, transparency, and training) nor intrinsic quality (the myriad of internal aircraft design and manufacturing criteria) genuinely valued and pursued diligently?

Cultural and Engineering Failings:  Sales Before Safety?

In its flagship publication, IEEE Spectrum, the Institute of Electrical and Electronics Engineers (IEEE) offers an analysis that make a strong case that business considerations for the 737 MAX trumped values of quality and safety, resulting in a flawed aircraft design that cost hundreds of lives.  

In “How the Boeing 737 Max Disaster Looks to a Software Developer:  Design shortcuts meant to make a new plane seem like an old, familiar one are to blame,” long-time pilot and software engineer Gregory Travis details, in aerodynamic and avionic terms, insights as to why this “737” is a very different aircraft than its predecessor. He summarizes that Boeing called the plane a 737 for reasons of cost, avoidance of regulatory scrutiny and avoidance of training that a new aircraft would require.

Underplaying the aerodynamic differences between the avionics systems of the 737 MAX 8 and its predecessors underscores the serious failures in the development of the 737 MAX 8’s software systems:  

  1. Developers with insufficient aviation domain experience;
  2. Poor oversight compared to that for hardware and overall aerodynamics;
  3. Lack of understanding or commitment to Agile as a framework for quality software systems development.

Some Thoughts on Culture at Boeing.

A few years ago I toured the Everett, WA plant where 787s are built, and my impression was that it was a huge factory, yet it was very quiet for mid-week, not the level of activity I would expect on a factory floor. A free workshop we facilitated showed it took 3 months to organize and complete a (in-situ) component test, however the actual time needed for testing was 1 to 4 hours. We had lots of advice on how to reduce that cycle time so testing could be completed faster. My impression was that the advice was ignored. Personally I was fascinated at the cultural differences between the plant producing the large aircraft in Everett, a northern suburb of Seattle, and the plant producing the small 737 aircraft in Renton, a southern suburb of Seattle. Like two different companies, the Renton plant seemed more fast paced, competitive and continuously improving, while the Everett plant was, well, quiet.

I know there are many great people at Boeing. They have some fantastic and safe products that I use almost every week, such as the previous generation of 737 planes. I use Boeing’s ability to produce the previous generation of 737s in Renton (a plane every 10 days per line, 42 per month) as an example of how dedicated Lean thinking can produce a fantastic manufacturing process and a great product. The people building the current 737s were not the people directing the development of the new aircraft with all the problems.

While social media has its negative points, one benefit is the transparency it can create, often illuminating problems organizations would prefer remain hidden. In this spirit of transparency, the last comments on culture I will leave to a blunt developer who worked for 1.5 years at Boeing.

“First, Boeing’s corporate culture is the worst I have ever experienced. All large corporations have a lot of internal issues and problems but nothing like the Lazy B. It was like working in a company designed by Kafka. I signed up at Boeing as a programmer. When I showed up at my first day of work, the first words out of my supervisor’s mouth were, “I don’t know why you are here, we have no need for programmers.” The Boeing interview process is done so that at no point, do you ever have contact or communication with the team you will be working with.”

Read his full comments are available on Reddit. His comments were regarding this Vox Video: The real reason Boeing’s new plane crashed twice.

Could Agile Foundations Have Prevented the Boeing 737 Max 8 Failures?

Absent Agile Foundation: Fail Early and Learn

The purpose of “fail early” is to discover successful outcomes in increments, steering to an ultimate completed product that works before full implementation. The core value is found in extensive testing and cutting losses quickly when something is not working. Had the 737 MAX 8’s larger, heavier and forward-mounted engines been mounted on a wing and floor tested, the discovery of the engine exhaust generating lift under the wing, causing it to “pitch up” with the application of power would have been known much sooner. If this result had been known and treated as unacceptable, then a different design, simply put, would have saved lives.

In the case of the 737 Max 8, the decision was to have software compensate for the extra lift generated by the engine exhaust. Boeing’s software, the Manoeuvring Characteristics Augmentation System (MCAS) was an attempt to use software to fix a flaw in the plane’s aerodynamic design. MCAS was needed because:

  1. The plane’s “angle of attack” (pitch or tilt) changes caused by the larger, heavier, and forward-shifted engines would likely exceed regulatory criteria of the U.S. Federal Aviation Administration (FAA), thereby risking aircraft certification, and causing Boeing and customer Airlines to incur pilot re-training costs and delays;
  2. A revised engine placement, novel wing design, or other hardware-based changes to fix the problem aerodynamically would be very costly;

In addition, because MCAS was “fixing” a design flaw, Boeing was not forthcoming about the MCAS operation with stakeholders:

  1. The MCAS, its function, and overrides to its function were communicated transparently to pilots, perhaps given re-certification and re-training risks;
  2. Key MCAS warning lights having been disabled or solely provided as an upgrade;
  3. The two separate flight management systems for pilot and co-pilot each measure the angle of attack with different sensors on either side of the plane. Pilots check both systems and sensors to validate whether Angle of Attack is being measured correctly. However the MCAS only took input from one sensor on one side of the plane, something a Pilot would have recognized immediately as a flawed design. However Pilots were not informed on how MCAS worked.
  4. Boeing has “standard procedures” for design, development, testing, documentation, training, and certification. Yet with MCAS it seems these procedures were not followed.

Absent Agile Foundation: Including Users in the Product Development Process

A critical quality element to a successful Agile implementation is connecting the development team to the end-users — directly and early-on.  The development team responsible for MCAS did not spend time in the cockpit with pilots to understand how they used their flight control systems and when they chose to ignore those systems. If the team had spent time with the Pilots, they would have understood how their users, the Pilots, do their work. That knowledge would have caused them to make different design decisions, more realistic tests, better documentation, and training informed by the pilot’s current practices.

A Culture of Profits Over People

Boeing’s cultural problems of prioritizing production and profits over quality don’t stop with the 737-Max. The New York Times recently published an expose on the production quality problems plaguing the 787 Dreamliner. The problems detailed in the article from many interviews and leaked documents indicate chronic problems, leading Qatar Airlines to refuse delivery on any 787s built in Charleston. The article paints a picture of management prioritizing production over quality and a desire to hide quality issues because they will slow down production.

Agile Adoption Now to Ensure Safety in the Future

So, how might service providers, IT organizations, and engineering firms introduce and sustain commitments to Agile so as not to fail their clients on quality and safety? Beyond Boeing, how might commitments to Agile by executives and managers, and alongside related quality paradigms, help align business priorities and development approaches to quality and safety? With software required to control an ever-increasing field of mission critical functions, it is time executives and organizations commit to Agile in the same way manufacturing companies increasingly commit to frameworks like the Toyota Production System or Lean.

Aligning to Customers Aligns with Success

Like Lean, Agile requires organizational change. Executives will need to step outside their comfort zone and work with collaborators to re-invent their organizations based on a deep commitment to their customers. By orienting to the customer, not the shareholder or the C-Suite, organizations align to value streams that are focused on improving their customers lives. In orienting to the customer, we quickly realize that the teams doing that work are essential to our success, and the better the teams the better the results. The closer the teams are to customers, the better they can meet their needs. Some of the world’s most valuable companies got there by being customer oriented and Agile. This reorientation is happening in many companies today, and yet many people in organizations today don’t see a reason to change. They don’t see their own personal interests reflected in this new paradigm.

Failures Beyond Boeing

The Boeing 737 Max 8 should be a warning to those who would put their personal interests ahead of their customer’s interests. So should the Volkswagen emissions scandal and The Wells Fargo account fraud scandal. These three are massive failures that have brought huge losses to shareholders, customers and employees. They have occurred because the organization is not oriented to the customer, it is oriented to shareholders and the C-Suite. According to the world’s best investor, that is exactly backwards:

“If a business does well, the stock eventually follows.” ~ Warren Buffet

  • -

Does Your Team Need Agile Coaching?

Tags : 

If you or your team have invested any amount of time into understanding Agile or Scrum, you may have realized that learning what to do and actually doing it are far from the same thing. You certainly will have experienced roadblocks if you have attempted adopting Agile or Scrum in an environment burdened with hierarchy, legacy systems that don’t comply with innovative methods, or people problems. (Read: Complex Project Failures: How Labels, Hierarchy & Ego Create Disasters in Management)

There are significant barriers an organization faces in becoming truly Agile… and this is normal. Some organizations, the most innovative, are sometimes able to overcome these barriers on their own. But usually, they cannot.

Value of Agile Coaching

Consider the following questions:

  • How many high performance athletes have Coaches? Why?
  • Should organizations with high performance goals have Coaches?
  • Does your organization have high performance goals? Do you?
  • Do you have a business Coach or sports Coach? Does it make a difference? How?
  • Are the similarities between high performance at work and sports enough to value coaching in the workplace?

Make the leap of faith that it is equally valuable to have a Coach to bring out the best in a high performing athlete and a high performing team. An Agile Coach can be the high performance Coach your organization is missing to bridge you from where you’re at to what you want to achieve.

What Does Agile Coaching Do For Team?

Let’s start with a goal. A goal of Scrum is effective product delivery by the team, so let’s base our goal on that metric.

Goal: The team is able to execute 80 to 100 per cent of what they planned every Sprint, in a stable and reliable manner. Furthermore, the team has the confidence and belief in their capacity to reliably deliver, and can show how their progress impacts target release dates.

There are important subtexts in this goal statement: Stable, Reliable, and Confident.

Stability and reliability show that the team understands three things very well:

  • the nature of the work
  • the availability and capacity of team members to do the work
  • their ability to deliver together within the Scrum Framework in the context of the organization

Confidence is an indicator of strength of belief in the stability and reliability of the system. The stable and reliable system provides psychological safety. Confidence means people feel they have the ability to speak up to challenge or support decisions that impact them.

How Much Coaching Does Your Team Need?

When introducing Scrum and Agile to a new organization, the coaching is focused on helping the Scrum Master, Product Owner, and Scrum Team learn their roles. It teaches them how to use the Scrum Framework.

When coaching a new team that is co-located in a single location, we want enough coaching to really understand the people and the business context.  However, our goal is for the team to become stable, reliable, and confident. So, we want the teams to also work on their own so they learn to be self-reliant.

Depending on the business context, we will coach two to three days per week. Many software teams we’ve worked with often achieve the stated goal (example above) in 4 months.

Ideal Environment Versus Reality

The complexity of the environment; the state (maturity) of Agile adoption in the organization; and the size of the organization are all factors that conspire to increase the time it takes for teams to reach the goal.

Our experience has been that non-software teams can take much longer. A key factor is how dependent the team is on other parts of the organization to deliver their product.

Dedicated team members learn Scrum faster; learn how to work with other teams faster, and waste less time switching between tasks. Dedicated team members improve stability and reliability.

If we are coaching more than one team, the goal is the same. There can be some synergy and time-savings if the teams are working on the same product since their Sprint planning, reviews, and retrospectives may overlap.

Can You Skimp on Coaching and Still Succeed?

A common request we hear from some new clients is “What about just having the Agile Coach come for Sprint Planning, Sprint Review and Retrospective? Isn’t that enough?”

As with all iterative and incremental approaches, the speed that value is accrued from Agile Coaching is related to the cadence of a feedback loop. With coaching interaction, 1 day per sprint on a sprint boundary (review, retro, and planning) the team will be able to receive feedback and coaching around those sprint boundary events. This is valuable in terms of the team’s understanding of those events and how they interact with each other and the goals for the product. However, the context will be limited to those events as the coach has not been privy to information and circumstances as they arise during the Sprint. This means information and situations that could be used to help the team improve are not used, so improvements will likely take longer and be slower.

For example, Product Backlog refinement is an important facet of iterative/incremental development as it sets the stage for successful Sprint planning. Backlog grooming discussions happen throughout the Sprint, not at the Sprint boundary. The effectiveness of the Sprint planning is usually directly proportional to the effectiveness of the backlog grooming/refining conversations. Without an Agile Coach present, Product Backlog refinement does not receive Coaching. (Read: Lessons from a 10-Year Long Product Backlog)

Similarly, the discussions, actions, and escalations for impediments and retrospective actions occur all throughout the sprints so the Coach cannot advocate and support the needed changes to make teams more effective during Sprint execution.

So, in short, skimping on Agile Coaching does not, in the end, help you succeed.

Maximize Your Chances to Hit the Goal and Maximize Value of Your Agile Coaching Investment

Have you ever had Physiotherapy treatment, hired a Personal Trainer to exercise with, or taken tutoring or lessons? In these situations we quickly recognize that the success of the relationship depends on both parties. A Personal Trainer or Physiotherapist can’t make their client do their exercises when they are not around. However, these Professionals can accelerate outcomes by working more intensively with motivated clients to help them understand what they need to do, to offer feedback on how to get better and to share different exercises and expertise when certain treatments are not working as expected.

Maximizing the benefits from an Agile Coach is similar, in that working together more intensively to remove impediments, to improve the team’s situation, has a faster payoff. If Scrum team members, the Scrum Master, the Product Owner, and the supporting stakeholders take Scrum seriously and leverage the knowledge of the Agile Coach to maximize their effectiveness in supporting the implementation, then this will also accelerate the value they receive from the Agile Coach.

Gaining Agile Coaching can significantly accelerate your Agile adoption by:

  1. helping your teams get better faster
  2. showing stakeholders the behaviors that best support Scrum
  3. sharing practices, techniques and ideas that have worked in other clients
  4. advising against techniques that don’t work or cause problems

Once the Scrum team has hit the goal and is able to execute 80 to 100 per cent of what they plan every Sprint, in a stable and reliable manner, we will applaud their success as they have achieved the first step. From here, they can begin to learn more advanced topics beyond basic Scrum.

Learning and improvement is not a destination, it is a journey.


  • -

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!!

order tamoxifen online