What is Systems Thinking Leadership?

  • -

Canada’s 150 Celebration Sale!

Tags : 

Kickstart innovation with Innovel’s Certified Scrum and Agile training this year!

If Canada’s first 150 years were built on hard work and resources, we think Canada’s future relies on creating products and services that customers far beyond our borders need and want.
 
Canada’s future relies on the innovation of its people. Innovel’s Scrum and Agile training will give you the tools you need to lead fast moving and innovative projects and product development.
 

To help do this, we’re celebrating:

Canada 150 Sale
Save $150 on every Innovel Certified Scrum training course for the rest of 2017.
 
This Canada 150 Sale discount can be applied to any posted rate including early bird rates (but cannot be combined with other discounts like group offers). 
 
We have many CSM and CSPO classes in locations across Canada for you or your team to attend. Visit our information pages for more details and to register soon:

Our sale is limited to the first 8 participants in each course, so we encouraging those looking for Certified Scrum Master® or Certified Scrum Product Owner® courses this Fall, to secure this price quickly.

SaveSave

SaveSave


  • -

Lessons from a 10-Year Long Product Backlog

Tags : 


FREE Workbook

Take the leap from traditional project management to Scrum with help from this free gift.​


Product Backlog Management Tools: When & Why?

I am often asked, “What tool should we use for Scrum?” or “What tool would you recommend for managing a large Product Backlog?”

Recently the Product Backlog question came up regarding a tool called CaseComplete, so I’d like to share my experience with managing Product Backlogs in complex product development.

The 10-Year Product Backlog Story

 In 2009, I was coaching an Agile transition with a large European software client who had 400 developers across 5 locations. We were using Excel to manage the Product Backlog (PBL) with 12+ Product Owners and it was very painful. The Product Backlog had 1200 items in it and represented 4 years of future work by the whole development organization.

Product Owners would edit their own copies and then have to merge their changes manually in multi-day meetings. We started looking at Requirements Management tools like DOORs, RequisitePro, Rally, and others. Since the company had a license for IBM RequisitePro, we attempted to use it. However, RequisitePro was very difficult and inflexible. In many ways, it was worse then Excel. So, after some real world user testing, we abandoned it.

The Product Owners continued to add Product Backlog items and last I heard, in 2012, the PBL contained over 3000 items and was virtually impossible to manage. It also represented a massive 10 year inventory of work.

How Agile is a 10-year Product Backlog? Of course, it’s not Agile at all. On average, any new item entering this queue will take 10 years to complete.

Saying “No” Decreases Inventory and Increases Agility

If your Product Backlog is so big and complex that you think you need a tool (beyond cards or Excel) then most likely the problem is your Product Backlog itself.

If the Product Backlog is too big and too complex then the solution in not a tool, the solution is to simplify your Product Backlog.

Agile Manifesto’s first value is individuals and interactions over processes and tools, and this is the key value to make product development successful.

If there are hundreds of software developers building one product, maybe a tool will be valuable. However, my experience is that these tools actually reduce the amount of collaboration and shared understanding between the people defining what is needed and the teams doing the work.

The Three-Month Product Backlog

When I am coaching product management staff (POs, BAs, Directors, etc.) these days, my advice is to keep your Product Backlog to at most three months of work. Yes, only three months (queue catcalls and shouts of “that’s impossible here!!”).

Beyond three months, I coach POs to tell stakeholders that they will come back and consider new items next sprint, but for now they cannot put it into the Product Backlog unless they are going to remove something else.

This shortens conversations with stakeholders greatly, and makes the Product Backlog much easier to manage since it is only three months long. It also has the nice effect of keeping stakeholders engaged when they need to be. If stakeholders can’t get their item in the next three months they may look for alternatives, and that is a good thing.

Saying “no” to stakeholders increases their agility since they can consider alternatives (for example, they may buy a solution) instead of waiting years and becoming very frustrated as they did in the company with the 10-year Product Backlog.

A three-month Product Backlog works very well because it provides product Agility and gets rid of the need for useless complicated tools for huge and hard to manage Product Backlogs.

I am not saying tools cannot provide some value. They can. However, tools often enable bad behaviors that reduce communication and Agility.

Remember, individuals and interactions over processes and tools.

 

 


  • -

Complex Project Failures: How Labels, Hierarchy & Ego Create Disasters in Management


FREE Workbook

Take the leap from traditional project management to Scrum with help from this free gift.​


I recently read an article and Facebook post that got under my skin.

Frankly, as an electrical engineer with 27 years experience in software and product development, a former member of APEGA, and owner of one of those “iron rings”, I disagree with almost everything in The Atlantic’s Programmers: Stop Calling Yourselves Engineers.

The article is clearly written from a place of ignorance about software development.

One of my missions as an Agile trainer, coach and industry leader is to debunk the myth that ego and hierarchy leads to success, and to demonstrate that collaboration is critical in our software-driven society.

A Case Study in Truth: Volkswagen Fail vs Toyota Success

The Atlantic article uses an example regarding Volkswagen citing “The Volkswagen diesel-emissions exploit was caused by a software failing, even if it seems to have been engineered, as it were, deliberately.”

This shows the author has little or no understanding of what happened at Volkswagen and failed to do the necessary research to find out. If he did, he would have discovered that managers told the engineers that 230 euro for the “add blue” emissions subsystem was too costly, and ordered them to find another way, without a budget.

Toyota is out-innovating and bringing higher quality than their competitors. Their management philosophy is “go and see.” Quite the opposite of Volkswagen’s management philosophy of “make it so.”

 

In my certified Scrum courses, this is what I refer to as “belief in magic”. Most of the dysfunction described by the author in this article is not because of the lack of detailed planning or intricate documents but rather bad management decisions that employees, engineering ring or not, are forced to comply with.

Look at it this way… with $100+ billions in failures in software development and IT over the last 40 years, will four years of studying math and an engineering certificate fix these problems?

No, it won’t. It’s not the job title or credentials that causes failure. It is the organization that leads failure.

Scrum, Agile, Computer Science, Engineering, and Reducing Risk

Scrum and Agile are becoming increasingly popular, as noted by LinkedIn’s top 10 careers for 2017. The reason is because Scrum and Agile are the most effective risk mitigation strategies we know for software development.

The complexity of large software products dwarfs the complexity of traditional engineering projects like bridges and buildings.

Now, a bridge and all the engineering complexity required to keep it safe is serious and safety is critical. In fact, a Quebec bridge disaster inspired the Ritual of the Calling of the Engineer (written by Rudyard Kipling) and the iron ring. But, in terms of design and engineering, software is far more complex.

Complex engineering infrastructure like transportation systems, the power grid or pipeline networks would be unmanageable without the far more complex software used to manage these systems. (Image: Shanghai Nanpu Bridge)

 

I have worked with brilliant people with advanced degrees in engineering and computer science. I have also worked with brilliant people who came to the world of software development from the fields of music and psychology. I have admired the huge talents of developers whose only education was through learning on their own. In one company I managed the senior product designer had a high school degree. His colleagues thought he was brilliant and so did I.

Bill Gates failed to complete his first year at Harvard. Does that make him any less of a person?

The Fail of Engineering & Software Without Organizational Change

The ideas in the original article were tried over and over for decades and they failed.

Companies like Google, Apple, Uber and Tesla are moving faster as they continually create tomorrow’s products today, while sleepy manufacturers take 4 years to release a new car that is the same as the old car.

I know this because these companies call me. They want to know how to work like Google and Facebook so they can innovate faster AND build quality in. Why should a farmer sit in a combine all day just to point it down a row of grain when it is possible to automate the machine’s navigation?

Smart People Seek to Make an Impact

A friend quit mechanical engineering after he learned that effectively all of the engineering calculations he had to do to design most components at his employer had been done in the 1940s and were published in tables. He went into IT because the work was more interesting to him since it was new and the problems weren’t solved.

One of my clients makes pacemakers and they use Scrum to build the software that resides in the pacemaker. They use Scrum and automated testing to demonstrate to the FDA that with every iteration (1 to 4 weeks) the working system has no bugs or defects.

Most of the failures cited in this article were failure of management to:

  1. understand technology
  2. empathize with the challenges of building and maintaining complex systems
  3. give staff the time to build quality in

Instead we see management treat IT and software development as purely a cost center without a clear connection to return on investment (ROI). This creates a “cheaper is better” mentality that causes huge dysfunction and waste (see my video on the $8 billion spent on the botched healthcare.gov rollout, a website saved by using Agile techniques and engineers from Google).

There are many problems you can’t engineer or code your way out of.

Organizational Change or Bust

Systems thinking and organizational design are potential solutions to fix the issues mentioned in the article. Many of these problems are rooted in managers making decisions about how the work should be done when they themselves are disconnected from how the work gets done. Would you appreciate having a hospital administrator instruct the surgeon on how to perform surgery on you? Probably only if the administrator is also an expert on your procedure.

Peter Senge wrote about systems thinking and organizational design years ago in the Fifth Discipline. There is no excuse to waste months and years and blame entire job functions when talented engineers, software developers, business managers, and others can create and deliver consumable, useful products as a team, every single week under a different organizational approach.


  • -

Agile Hits the Top 10 on LinkedIn

LinkedIn just released an article on the top career positions based on LinkedIn job posting data in the United States. Leadership roles with Agile and Scrum were in 4 of the top 10 roles. How do you think this relates globally or to the Canadian situation, specifically? If you are a Canadian Agile Leader, pop over to our LinkedIn Group to discuss. 

Below are the top Agile roles according to LinkedIn:

5. Product Manager
Median Base Salary: $97,500
Job Openings (YoY Growth): 3,000+ (11%)
Career Advancement Score (out of 10): 8.0
Top Skills: Product Development, Competitive Analysis, Product Launch, Cross-Functional Team Leadership, Marketing Strategy

7. Technical Program Manager
Median Base Salary: $129,000
Job Openings (YoY Growth): 500+ (49%)
Career Advancement Score (out of 10): 8.0
Top Skills: Agile Methodologies, Software Project Management, Software Development Life Cycle, Scrum, Cloud Computing

8. Program Manager
Median Base Salary: $97,400
Job Openings (YoY Growth): 2,300+ (17%)
Career Advancement Score (out of 10): 7.0
Top Skills: Project Management, Project Portfolio Management, Project Delivery, Vendor Management, Business Process Improvement

10. Scrum Master
Median Base Salary: $100,000
Job Openings (YoY Growth): 400+ (104%)
Career Advancement Score (out of 10): 8.0
Top Skills: Agile Methodologies, Software Project Management, Scrum, Requirements Analysis, SQL

Job rankings were based on a weighted score across five areas: salary, career advancement, number of job openings in the U.S., year-over-year growth in job openings, and widespread regional availability. We looked at data from member profiles, job openings and salaries to rank the best jobs for career opportunity. If the scores were tied, we ranked the title with the most open job listings higher.

You’ll find the full LinkedIn report here:
https://blog.linkedin.com/2017/january/20/linkedin-data-reveals-the-most-promising-jobs-of-2017


  • -

Innovel Announces New Certified Scrum Training Courses in Canada

Tags : 

I am really excited to be back Canada with public Scrum certification courses, after years honing our private and public Scrum training in international markets.

Early bird rates are available and registration is now open in Toronto, Calgary, Edmonton, Vancouver and Montreal:

More fun, More value, More Retention

We offer more than the basics of Scrum in our CSM® courses. While we will teach you about the Scrum framework, the roles, and the techniques to plan and implement Scrum in your projects, we also make this very interactive and enjoyable 2-day workshop style class useful with discussion exercises and group-oriented simulations. 

And, our new Certified Scrum Master Plus™ is CSM® with a 3rd day add-on to help with scaling (multi-team development) questions, Scrum Master coaching and facilitation skills, and creating an implementation plan for your first Scrum. Our students often say that the CSM should be a 3-day course to allow more time to absorb and understand the ideas. They asked, we created this highly beneficial third day, exclusively available with Innovel.

Certified Scrum Product Owner® Training by Innovel will show you how to effectively work with a Scrum team to take a product from idea to implementation. While we cover Scrum basics, this course focuses on Agile Product Management, Lean Startup, working with stakeholders, prioritization, reducing risk and maximizing business value.

Contact rdymond@innovel.net if you would like more information about our private or public training courses or to request a group discount code (10% off for groups of 3 more).


  • -

Team Team Team: Team Building or Team Work?

Tags : 

Team building or team work? Team building is a bit of a strange idea. Think of the great sports teams or project teams of all time, did they do “trust falls” or high ropes courses for team building? Great teams form when good people learn to work together, to trust each other, and have an environment where people can learn and grow into a great team.

“OK, what are the top 10 books on team building?”

How many books do you need? If I recommended 10, how many would you read? How many work related books did you read last month or last year?

I would recommend starting with 1 video based on a TED talk by Daniel Pink.

Then read the book that the video is based on so its points sink in.

Drive: The Surprising Truth About What Motivates Us: Daniel H. Pink: 8601234640691: Amazon.com: Books

Then read up on one framework/model for thinking about team formation:

Tuckman’s stages of group development – Wikipedia

A recent article on teamwork covers some of the challenges of modern team work where team members maybe dispersed (its OK, has some good examples)

The Secrets of Great Teamwork

and finally this classic book by Richard Hackman on leading teams, that while a bit dated supports many of the ideas presented above.

Leading Teams: Setting the Stage for Great Performances

Leading Teams Book Cover

Richard Hackman, one of the world’s leading experts on group and organizational behavior, argues that teams perform at their best when leaders create conditions that allow them to manage themselves effectively. Leading Teams is not about subscribing to a specific formula or leadership style, says Hackman. Rather, it is about applying a concise set of guiding principles to each unique group situation–and doing so in the leader’s own idiosyncratic way. Based on extensive research and using compelling examples ranging from orchestras to airline cockpit crews, Leading Teams identifies five essential conditions–a stable team, a clear and engaging direction, an enabling team structure, a supportive organizational context, and the availability of competent coaching–that greatly enhance the likelihood of team success. The book offers a practical framework that leaders can use to muster personal skills and organizational resources to create and sustain the five key conditions and shows how those conditions can launch a team onto a trajectory of increasing effectiveness. Authoritative and astutely realistic, Leading Teams offers a new and provocative way of thinking about and leading work teams in any organizational setting.

 

…then there is how not to do it: TEAM TEAM TEAM from IT Crowd.

Use those as jumping off points to additional learning.

Finally, none of this matters if you do not have the environment for effective team to arise. For that you should use Scrum, a team based framework for doing the most important work first, in short cycles, and using feedback (retrospectives) to continually improve the environment and the team.


  • -

What is Systems Thinking Leadership?

Tags : 

A Rube Goldberg Machine

A Rube Goldberg Machine. Photo by freshwater2006

The conventional wisdom is that leadership is associated with a role. It is something to be left to Bosses, Managers, and those who have authority. This model worked fine when markets moved slowly and competitors had the same leadership model. Today, business is very different. Markets change very quickly, competitors continually try to take your customers, and the lifespan of companies has shrunk . “The average lifespan of a company listed in the S&P 500 index of leading US companies has decreased by more than 50 years in the last century, from 67 years in the 1920s to just 15 years today, according to Professor Richard Foster from Yale University. Today’s rate of change “is at a faster pace than ever.” If companies are to survive, they will need a model for leadership that is different than in the past, because, as the accelerated corporate death rate shows, relying on the old methods of leadership has Darwinian implications.

Leadership must move out of the hierarchy and to the front lines. It must move from one or a few brains, to all the brains in the organization. In 2016 Leadership is not a role, it is a task, best accomplished by the person with the most/best information at that time. In most organizations, the person with the best information is rarely the Boss or the Manager, because almost all of their information is second hand. Leadership needs to be delegated from Bosses and Managers to the people doing the work who have the best information. This has implications for everyone. It means that positional power is not as important to company survival, but too much positional power can threaten company survival. So how do we enable Leadership at the front lines? Training? Coaching? Empowering? While all those things can help, the answer is NO. If you want a company that survives and thrives in 2016 and beyond, then focus on Organizational Design. The structure of your organization defines how decisions are made, how people are rewarded, what positions have power, what policies are enforced and by whom. Changing the organizational structure with the specific goal of enabling Leadership at the front lines is a crucial step building a company that will last. This is Systems Thinking Leadership. #Scrum #Lean #TPS #LeSS #LeanStartup #CustomerDevelopment #Neuropsychology #NeuroLeadership #Holacracy #Sociocracy #Valve #WLGore #Semco #Facebook #TaichiOhno #JeffSutherland #PeterSenge #JohnSeddon #CraigLarman #DanPink #DavidRock #SteveBlank


  • -

Improve Measurably with Improvement Stories

Tags : 

Americas cup 2013 race

The Americas Cup, started in 1851, is the oldest international sporting trophy. In 2010 the Cup was disrupted by teams using multi-hull trimarans with fixed wings instead of sails. By 2013 fixed wing catamarans with hydrofoils had sailed at 3 times wind speed.

One of the continuing challenges we see with some Scrum teams is a lack of improvement in how they work over time. There are many reasons for this, however continuous improvement is the cornerstone of Lean thinking, and the reason we have a retrospective in Scrum.

There are many ways to improve. Lean thinkers advocate the A3 plan for improvement, an excellent way of thinking about larger improvement efforts. You will often hear Lean thinkers talk about “Kaizen events,” Kaizen is Japanese for improvement, and these events are focused efforts to implement improvement. In Lean, Kaizen is a mindset, the search for improvement is continual and a critical part of day to day work of everyone.

In the software community we have numerous good ideas for improvement including Retrospectives, Devops, and automation.

However all improvement starts with deciding to value making the improvement over producing something else, like a feature or a bug fix. This is usually where the problem starts. Teams and Product Owners tend to value new functionality over improvement. From the perspective of a long lived product development effort, every improvement made is an investment that pays off for the lifetime of the product. For example an improvement that saves a team member 10 minutes every day may seem too small, however if that 10 minutes is saved over a 2 year period, that adds up to about 5000 minutes or 83 hours. That’s more than two weeks of productive time that can be spent on more valuable activities. A recent study of the most productive software developers at Google found that they spent approximately 1/3 of their time building tools to improve or automate their work environment. If the best of the best spend 33% of their time sharpening the saw, then shouldn’t the rest of us should make similar investments?

Changes to Scrum that prioritize improvement

Jeff Sutherland, the inventor of Scrum, in discussion with Lean expert Hugo Heitz realized that Scrum teams weren’t realizing their potential because they didn’t proritize improvement. Since then Jeff has advocated the pattern “Scrumming the Scrum” where teams use the Scrum cycle to improve Scrum. The twist is that the improvement is the first thing the teams do, before working on any new functionality. To implement this change the Scrum board gets another swim lane, the improvement or kaizen lane.

scrum board with improvement lane

By breaking out the improvement in its own lane and putting it a the top board, we attach the visual and social importance to improvement. We are making a clear statement to stakeholders that investing in improving how we work is more important then any one piece of functionality.

Describing incremental improvements

User Stories first emerged from the XP community in 1998 as part of the planning game. Over the past two decades there has been much work on improving User Stories and Acceptance Criteria. This thinking has clarified both the mechanics of User Stories and the value of the different features of the format. There have also been a number of variations developed. As the Agile community refined User Stories, it also borrowed good ideas from the EVO methodology developed by Tom Gilb. Gilb defined System Qualities to specify needs the system must meet that were not features (non-functional requirements).

To date the Agile community hasn’t really defined a good way of describing improvements. The Lean community has A3 plans that are very are useful but often are too large to fit in a Sprint. The A3 format also tends to be a mini project with a number of changes, deliverables and measures, while in Agile and Scrum we use iterative and incremental delivery. So we need a way to define improvement that leverages iterative delivery and our previous learning about describing user and system needs.

What is an improvement? This is an interesting question. Is it a feature? Maybe. Is it a process change? Possibly. Is it a tool? Could be. Is it a social agreement? The interesting thing about improvements is there is a wide range of things we may do to improve our situation and how we work. Given there is such a wide range of possibilities, this is similar to the Feature/function in User Stories. So let’s look at how we can leverage user story thinking for improvements.

User stories consist of 4 parts:

  1. The user role
  2. The feature or function
  3. The benefit or goal we are trying to achieve
  4. A definition of done in the form of Acceptance Criteria

In more general terms we can say that user stories are of the form Who, What and Why. User stories are powerful because we bookend the thing we plan to build with two important pieces of information, who is going to use it and why they want it. This means we need to find an actual user and validate that they really do want the functionality. We also need to understand why they want it in order to prioritize it against all the other things we might do for our users.

Looking at the work of implementing improvements we see a similar need. There are many different improvements we can make, how do we prioritize them? Who benefits from the improvement? What benefit do we expect to receive? How do we know we received the benefit? Given these questions are similar to questions we have  answered with User Stories we can leverage this thinking.

Measuring Improvement

While it is great to say we have improved, it is more interesting to say we have improved by a measurable amount. If we are investing time and energy in improvements that could be spent on functionality that generates business value, then we should try to show how improvements provide quantifiable benefits. To define a quantifiable improvement we need to determine:

  • What we are measuring
  • How we will measure it
  • The current state
  • The (anticipated) improved state*

*this is likely just a guess

By making clear statements about measurement we force questions about methodology and we make it more transparent how we intend to quantify the outcomes.

Creating an improvement story

Defining “who” in an improvement story:

Since improvement stories may impact team, process, stakeholders, users, management, we have a broad number of potential roles. Choose the role most closely associated with the benefit, and involve them with measuring the improvement.

Defining “what” in an improvement story:

The improvement needs to be do-able. This means if we pull it we can get it done within the Sprint, and we can see a result from the work that provides a benefit we can take advantage of next sprint.

Defining “why” in an improvement story:

Why are we making the improvement? What waste are we eliminating? What aspect of work is improved? What increases do we expect to see for the defined Role?

Knowing when we have improved:

It isn’t enough to say we have improved. We need to find ways to quantify the benefits. How can we measure the improvement?

Example improvement story:

During their retrospective, a Scrum team comes up with a number of improvements they could make in the next Sprint. The team decides there are two improvements they will tackle in the next sprint, reducing the time to install new builds onto the QA server, and improving communication with another team who they rely on.

The team crafts the improvement story together during the retrospective.

Starting with “why”:

The team defines the expected benefits, with testers talking about the time wasted waiting for a new build and developers complaining about getting hassled by testers for a build, having to stop working on a feature to run through a bunch of tedious manual deployment steps. Both developers and testers will benefit, so they decide to write the improvement story both ways for fun. The testers do some quick calculations and determine that on average they will save an hour per day per tester. The developers determine they will save 15 minutes per day per developer. Both developers and testers expect this change will improve team working relations by eliminating at least 2 or 3 conflicts per week, reduce multi-tasking and make the team happier.

What can we do to improve this sprint?:

The team discusses the possible solutions they could pursue, from implementing a new build server to automating database configuration. As a first step the team agrees to write deployment scripts that will automate copying the current build from the development build server to the QA server and run a smoke test. Since database changes are less common they choose to defer automating database updates to a future improvement. The team writes up the improvement story from the tester point of view:

Automate QA Builds – Tester  

As a tester I can run a script to get the latest working build on the QA server so that I save 20 hours per sprint and don’t have annoying conversations with developers.

We know we will have improved when:

  • We have reduced tester wait time as measured by testers using a stop watch
    • From the current state of 20 hours to 5 or less hours per sprint
  • We have reduced team conflict about getting builds as measured by red postits on the scrum board
    • From the current state of 4 to 6 conflicts per sprint to 1 or 2 per sprint

  

And then they write it from the developer point of view:

Automate QA Builds – Developer

As a developer I can write a script to automate getting the latest working build on the QA server so that the testers will stop bothering me 3+ times per day for the latest builds.

We know we will have improved when:

  • We have reduced number of times I am bothered as measured by “build please” postits on my monitor
    • From the current state of 30 times per sprint to 5 or less per sprint
  • We have reduced team conflict about getting builds as measured by red postits on the scrum board
    • From the current state of 4 to 6 conflicts per sprint to 1 or 2 per sprint
  • We have reduced the time to get feedback on my bug fixes as measured by the bug tracker
    • From 3-4 days to 1-2 days 

In creating these improvement stories the team has agreed on what they will measure and how they will measure it. By agreeing to put red postits on the Scrum board every time there is a conflict the team creates visibility about the aggravation (or lack of) caused by the friction of the current system.

The team realizes there is an additional important benefit from making the improvement. Not only will it eliminate wait time and frustration for team members, it will also speed up feature development, since testing, bug fixes and validation will happen in a shorter timeframe. The team likes this benefit but isn’t sure how to measure it, so they leave it as a topic for next retrospective.

Sizing and Decomposition

As with User Stories, Improvement Stories can be written at both a high level and detail level. They can be sized using story points, and can be decomposed into the specific tasks the team needs to get the Improvement implemented.

Improvement Story Templates

There are two different templates you can try for creating improvement stories

Template B “Start with why.” This template emphasizes the importance of why more than the standard template.

improvementstorytemplateB

 

Template A is likely more familiar to most people who are using User Stories.

improvementstorytemplateA

 

We hope adding improvement stories will help you implement continuous improvement within your team and organization. Stay tuned to Innovel for additional writing and examples on improvement stories.


  • -

What do you know about speed 1/5? Boeing 737 Final Assembly

Tags : 

How long does it take to do the final assembly of a Boeing 737? 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 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. Contact us for training and coaching in Lean, Agile and Scrum.

A timelapse of a Boeing 737 being assembled.


  • -

How can the CEO make the software teams deliver more features faster?

Tags : 

I recently provided some free advice on Linkedin. 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. We’ll go out of business if we don’t have [Feature]
    2. It will cost us lots of money but we won’t go out of business if we don’t have [Feature]
    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

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