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:
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.
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
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?”
My colleague Mishkin Berteig started his Agile Advice blog in 2005 when we were both doing Agile coaching for teams at Capital One. His blog was one of my favorite Agile blogs, he was getting out the lessons we were learning and providing smart succinct advice. In many ways Mishkin’s blog was ahead of its time, offering sage advice to issues and situations that many people had yet to come across. Mishkin has taken his blog content, tuned it up and added additional interesting stories in his new ebook Agile Advice. You can check out the blog for many great ideas, while the ebook is a more convenient format for those looking to improve their coaching and Agile transition knowledge.
I was recently cleaning out a storage area and came across one of the prototypes from a startup I co-founded in 1993. It is a prototype battery powered portable digital audio sound processor for the hearing impaired.
At the time my partner and I were working on a joint venture project to pioneer the first generation of all digital hearing aids. The hearing aid project was tough because the enormous constraints of a very small device that will run on very low power continuously for days. In learning about hearing aids we realized that they are not good for listening to music. Hearing aids have a very limited frequency range, so low and high frequencies are not amplified. Listening through hearing aids is sort of like listening to an AM radio, but worse. The limitations of analog technology caused a technical barrier to better quality. The other main limitation was that hearing aid users wore them for long periods so they demanded convenience and small discrete size above all else.
The big idea
We realized that the hearing impaired could hear much more music and have a great listening experience if they had a device that would treat the full spectrum of sound available to their impaired ears. Headphone, Walkmans, and portable CD players were common, so people were willing to carry music devices. We envisioned a portable device that you could take to the concert or use in your home.
Testing our idea
To be able to test our idea we ran some quick tests using a PC with an audio card. We processed some music with hearing loss algorithms and did A/B testing with a few hearing impaired to see if they notice a difference. We got mildly positive results. However testing in a Lab is quite different than a user using this processing in their own home or wherever they needed it. We also wanted to be able to test different settings and algorithms for compensating hearing loss for music. This meant we had to build a portable prototype that would allow us to program different processing ideas quickly, yet would run for a few hours on a battery. We also needed to do it for the lowest cost in the shortest amount of time, since this was money from our own pockets and time from our evenings and weekends.
Building the prototype
We built the prototype using a combination of off the shelf components and custom circuits. The first consideration was could we power the device circuitry using a battery? We discovered we could use a large rechargeable cell phone battery and a switching power supply component to get the power we needed. Around that time Motorola released an evaluation board for their 56002 Digital Signal Processor (DSP). I had been programming this DSP off an on for 4 years and it was excellent for audio processing, so we had our main logic board and processor. Most evaluation systems need some adjusting to your application, and this was the case for us. In additions to adding battery driven power supply, we needed to increase the system’s memory and add flash memory to store the settings and programs. We also needed to add buttons and LEDs for users to control the settings and volume. We also added a high quality digital audio interface to connect headphones, a microphone and line audio inputs for sources such as a CD player.
Testing with users
A number of hearing impaired users volunteered to test the system for us. We set them up with 4 different programs that they could select and a volume control they could adjust. We then sent them off with the device in a waist pack with the goal of using the device whenever they listened to music or went to a show. We also asked them to compare the quality of music and audio to their hearing aids. In the device we could track what programs and volume levels they were using. After a number of field tests, users reported mild improvements in listening to music, and a preference for certain settings in the device. The algorithms I had developed were working, however I knew we could continue to greatly improve the effectiveness of the hearing compensation processing.
The missing link – distribution
We proceeded with marketing and sales discussions with Audiologists. Audiologists are the Medical clinicians who test people’s hearing and prescribe hearing aids. This was the natural channel for our device, since it would need to be customized for the hearing impairment of the user. In learning about Audiologists’ business we discovered hearing aid manufacturers were heavily incentivizing them to sell hearing aids with high margins, discounts and free trips. A good quality hearing aid cost on the order of $800 to $1000 per device. Because Audiologists were focused on selling hearing aids to improve speech perception, there was little interest in offering our product to the hearing impaired. In doing our market research we found a simple device that offered some of our features for amplifying audio without the ability to do custom hearing compensation. Sales for this device were struggling and Audiologists were lukewarm to the device. Hearing aids were so expensive that most customers would only pay for them. The high margins hearing aids provided Audiologists meant they’d rather sell and fit hearing aids then a specialized device for music and audio.
After more conversations and demonstrations we put the business idea and this prototype on the shelf. We saw that while there was a need in the market and the technical solution to meet that need, the realities of the distribution channel meant the device would likely not succeed in reaching the customers. Trying to build an independent marketing and distribution channel through pro-audio retail channels such as stores was explored, but looked overwhelming and risky. The devices required hearing testing for baseline data, hearing compensation and user validation, a process far too complicated for a retail setting.
Our expensive lesson: If you are doing a Startup and using Lean Startup methods, identifying a need in the market and the solution is not enough. We found a need and a solution, we tested it and proved our solution worked. We discovered that you also need to prove you can get your solution into your customer’s hands. Perhaps now, 20 years later, we could do something similar with a smart phone. The challenge of getting the product properly configured for a user’s specific hearing loss remains.
I am ever grateful to my fellow investors/learners in this experiment:
Dr. Abram Gamer and Don LaFont.
– Robin Dymond.
I returned to Calgary Alberta Canada after 8 years living in Virginia and working with tech companies in the US and Europe. I still work with companies in US and Europe. I was quite involved with Calgary’s nascent startup community from 1996-2004, either with my own ventures or working with others. During that time I founded the TBL Napkin, a tech entrepreneur’s networking group that met for 3 years until the tech crash killed interest in it. At those events we hatched the idea that we eventually turned into the Banff Venture Forum, an investment forum for tech and energy startups in western Canada and it is still going strong.
Starting a company in Calgary has its own pros and cons, and while it is neither the best nor worst place in the world, Calgarians tend to have some blind spots, so here are some key points to keep in mind. I think these lessons apply to any startup that is not located in a technology hub.
1. Too much and too little money.
While Calgary has a huge and very wealthy oil and gas sector, that wealth and the expertise that comes with it doesn’t translate to technology companies. The mindset in oil and gas is completely different, how you start companies is different, and how you grow is different. So after many losses investing in tech, most O&G money stays in O&G where they understand the business. This means chasing investment from O&G people is valuable time wasted. The problem for startups is that all that wealth drives up people costs, and while sweat equity and shares work in the Valley, they simply don’t have the same value here.
2. Cashflow is king
The vast majority successful Calgary startups that grew to successful businesses focused on real cash-flow from real customers (not advertising). Cashflow early has two positive effects, it forces you to really listen to customers, and it provides immediate market based feedback on your idea/plans. Since Calgary sucks for raising tech startup money, real customer cash in the door really reduces the startup pain of debt, credit cards, family loans, stress, etc. This also means that capital intensive or infrastructure type companies (i.e. networking tech, hardware, nano tech etc.) that require lots of capital and/or long sales cycles should be avoided, or take your idea and move to where the customers and the financing are located. Same goes for advertising based companies.
3. Nobody knows your name
Calgary or most other Canadian and European cities are just not in the map in the US. In 8 of years living on the US east coast, it was rare that I would meet someone who had heard of Calgary, let alone know where it is. When I said Calgary, I could have been saying Riga Latvia. When I said Calgary was like Denver, it didn’t help, since they didn’t know where Denver was either. While you can say they are ignorant, consider that in a 6 hour drive you can go from Richmond Virginia through Washington DC, Baltimore, Philadelphia, New Jersey and New York city, not to mention all the smaller cities and suburbs. Drive 6 hours from Calgary and… well one more hour and we’ll get to Saskatoon! From Northern Virginia to Boston, over 50 million people occupy just 2% of the US land mass. People build very large successful businesses that in only exist in that small East coast corridor. Chances are you could be competing with a startup from that area, and they can drive to the customers. So you need to think about how you will differentiate your company while minimizing the potential disadvantage your location.
4. Do other stuff to pay bills
Calgary’s Smart technologies started out distributing and selling conference room equipment, projectors, etc, and did that for many years before and during the development of their smart board technology. Numerous companies have used consulting to pay the bills while they worked on the product or paid others to work on it. The best deal is if you can find a customer to fund your development because they really want what you can provide. Just make sure you retain ownership/marketing rights.
5. Go park yourself
The founder of Calgary’s critical mass parked himself in New York for long periods of time, and went up and down Madison avenue trying to sell Golf instruction CDROMs. That led him to landing a web site design contract for Mercedes Benz. At the time, critical mass didn’t know much about the web. A Calgary based company that built chat services for commerce web sites moved to LA to be physically close to their customers. Two years later Ask Jeeves bought them for XXX hundred million. If you need to sell to companies in Boston, hire a local sales person and go sell there with them until you know the roads and lobbies/offices of those companies by heart. You will then learn if your product is really needed (Golf CDROM? No thanks) or if you should be doing something else.
6. Stay small and manage the burn closely
You need people to make progress, but you also need feedback, answers and real information about the market, which means lots of learning for the founders. Learning is actually more important then building product. Learning progress is understanding what the market really needs and how to deliver it with the least amount of work and (borrowed) money. Find cheap ways of getting noticed, and be relentless about talking with potential customers and experts in your market. Give yourself a point every time you ask a question and subtract two points for every statement you make. The second mouse gets the cheese. All successful businesses have a simple economic equation at their core (even yours!). Know your equation forwards, backwards, and know all the factors that influence it.
7. If you don’t succeed, welcome to the club
Tech startups fail 90% of the time. So treat doing a startup as a learning experience and a chance to do something you have dreamed about doing. If your startup doesn’t succeed, well chances are you learned much more then you thought you would, and you have some scars to show for it. People who know about startups respect the attempt, and will be interested in hearing your stories and sharing theirs.
8. Press replay
A group of Calgary based entrepreneurs have been working the business model of direct media and font sales since the early 90s with Image Club Graphics, (sold to Aldus/Adobe Studios) to Eyewire (sold to Getty) to Veer (sold to Corbis) to iStockphoto (sold to Getty) to Stocksy and Dissolve. While this is neither original or particularly creative, it is effective since entrepreneurs can reuse business assets like contacts and refine the specific knowledge of that business. A similar thing has occurred in security software, where some Calgarians built an expertise in security software products and have continued to start, build and sell companies in that business domain.
Doing a startup takes guts. Doing it in Calgary increases the difficulty, but hey if my friends at Target Process can bootstrap development of an Agile Project Management tool from the very poor dictatorship of Minsk Belarus, why can’t you build your startup here? By the way, Target Process has sold 200+ seat licenses to Calgary’s Smart Technologies.
Robin Dymond, CST is an international trainer and consultant in Scrum, Agile, and Lean methods. He offers certified Scrum Master, Product Owner, Lean and Kanban training, and has trained over 3000 people in Canada, USA and Europe. A speaker and author, he’s presented keynote talks and sessions at conferences including Agile Eastern Europe, Agile 20XX and others. He is President of Innovel International Inc. Dymond has 24 years experience in software and a BScEE from University of Calgary.
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:
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.
Reviews of SAFe Program Consultant (SPC) training on the Scaled Agile Framework (SAFe), from Agile and Scrum experts
I have been following with interest the Scaled Agile Framework and its increasing popularity. There have been a number of reviews of the training to become an SPC or SAFe Process Consultant. I am also interested because SAFe came out of work done by Dean Leffingwell and other consultants at NAVTEQ in the US in 2010-2011. At the time I was providing Certified Scrum training to NAVTEQ subsidiaries in Germany who were implementing Scrum. I did not work with the US groups, however I am familiar with what was happening at NAVTEQ at the time. So I think any review of SAFe should include how it helped or did not help NAVTEQ be more successful as an organization. In the last few years since implementing SAFe, NAVTEQ has gone through a major downsizing, been acquired by Nokia, and then shrank some more. Speaking with a former Director from NAVTEQ now at another GIS client of mine, the automotive division is doing OK, but the rest of the company struggling and shrinking in the face of competition from Google and others. There are many reasons why companies fail, and we cannot blame SAFe for the shortcomings of NAVTEQ’s organizational culture and business model. However we can and should ask: how did SAFe help NAVTEQ?
In reviews the Scaled Agile Framework and SPC training, a number of experts Agile and Scrum have commented on their experience in the training, the training style, and the substance of the ideas in SAFe. Below are links to expert reviews of SAFe and SPC training.
Agile experts Ron Jeffries and Chet Hendrickson who are authors on extreme programming and Scrum, consultants and trainers recently took the SPC training in Washington DC. Ron’s review takes the stance that SAFe has some good things that Scrum or XP do not address, and he goes through those points in detail. Ron is an excellent writer and thinker, and I enjoyed his analysis of SAFe and the training. I think this is the best review so far. Scaled Agile Framework. SAFe: Good but not good enough.
Peter Saddington, a fellow Scrum trainer and consultant based in the DC area recently took the SPC course in Washington DC. Peter gives a balanced review of what he sees as the pros and cons of SAFe. While he likes Lean aspects SAFe has borrowed, he thinks the recommended “one week” roll out period carries significant risk. Peter strives to be open to the ideas that are contrary to some of the core principles and values of Agile. His highest praise is for SAFe’s marketing. Review of the Scaled Agile Framework SAFe SPC training and ideas
Scrum trainer Daniel Gullo recently took the Scaled Agile Framework and SPC training and reflected on the ideas and how they compared to his experiences working on Agile adoptions in large organizations. Daniel was also a agile consultant at NAVTEQ helping them adopt Scrum while the Scaled Agile Framework was first being implemented at NAVTEQ. “As long as I am able to work with a client implementing “SAFe” and we are allowed to tailor it to include the helpful parts and throw out the harmful parts, I don’t see anything really evil or wrong with SAFe here. What we are left with is doing precisely what I have already been doing for the last 8 years: looking for how to instill the values and principles Agile and Lean in the culture of an organization so that a paradigm shift happens.” Review of the Scaled Agile Framework SAFe SPC training and reflection on SAFe compared to Agile Coaching experiences
David Snowden, creator of the Cynefin (pronounced Kan av in) framework, a practical application of complexity theory to management science, recently weighed in on SAFe. In Dave’s post he weighs in on SAFe’s linear model and one size fits all approach. Snowden’s background is in complexity theory, and he knows that simple linear approaches fail to solve complex problems. Dave’s evaluation of SAFe is that it is not Agile. SAFe: the infantilism of management
Enjoy the reviews of the Scaled Agile Framework and SPC training. I will post more reviews from experienced Agilists on SAFe and the SPC training.
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 :).
Artwork “Post Apocalyptic Data Hunter: RONIX” by Steven Rodig at PCBCreations.com
With the massive failure of the healthcare.gov launch in the US, people are talking about why such an important software development initiative turned into such a failure. The US however is not alone in these kinds of failures. The UK government spent 10 years and 12 billion pounds on the failed NHS-IT electronic patient records program. Now 12 billion pounds is about 16 billion Euros or 20 billion US dollars. Ouch! I picture the Queen in earlier times shouting “off with their heads!” Instead the UK government started listening to people who knew about Agile and technology development. The UK Government has created the Government Digital Services, GDS, a 300 person department with the skills to deliver digital services online. In a recent interview with NPR, Mike Bracken, head of the UK Government’s GDS discussed the successes the GDS initiative has had in the two years since it was formed. Bracken mentions many Agile principles GDS are using to deliver a government that is digital at its core. Some of the highlights are:
Optimizing for business value: GDS is only going after the processes and services most used by citizens, such as passports, tax filing, benefits, etc. Within these areas they further optimize, so GDS is delivering digital versions of the highest value services first. Some processes and services may never be automated because the business value is not there, and that is OK.
Incremental delivery: GDS is delivering services in an iterative and incremental fashion. They are not trying to get it all right the first time. Instead they are getting the most important parts right, and then learning what works and what needs improvement.
Cross functional teams: GDS teams are cross functional, with developers, process and policy experts, UI designers, testers, etc.
Collaboration over contract negotiation: GDS has thrown out all of the traditional procurement processes and procedures. Instead of building contracts based on some wild ass guess wrapped in 300 pages of documentation, GDS admits they have no idea of where or what they need to do in 3, 5, or 10 years. Instead they focus on working collaboratively with users and stakeholders, quickly (1-3 weeks) delivering small amounts of working tested software to their users and getting their feedback.
Bracken was visiting Washington D.C. to talk to government officials and influencers to help them understand how the UK government is bringing digital services in a fast and cost effective manner to its Citizens. For everyone’s sake, I hope the bureaucrats in DC are listening. The $600 million spent could be a more cost effective lesson than the UK, or it could be a failure that is repeated over and over, just like in the movie Groundhog Day.
This 2 day course covers how to use Scrum to manage your Agile projects. Students gain an understanding of Agile principles, Scrum practices, and how to manage the Scrum process. Recommended for project managers, technical managers, and technical leads.
Current classes are listed on the Scrum Training site.
This 2 day immersive training is great for teams who are looking to adopt Agile for their project. Team members come away with a solid understanding of how to work day to day on an Agile project, how it changes their role and what they should expect. It covers Lean, Agile, and Scrum, with a focus on the Scrum project framework.