canadian pharmacy cialis www.canadian-drug-mart.com/

Tag Archives: Agile mindset

  • -

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.

 


  • -

Lessons from a 10-Year Long Product Backlog

Tags : 

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.

 

 


  • -

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. Leadership is no longer a role, it is a task. This task is 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 these Bosses and Managers to the people doing the work with 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 now 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.


  • -

Lean thinking and speed of Boeing 737 Final Assembly

Tags : 

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

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

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

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

Watch a timelapse of a Boeing 737 being assembled.


  • -

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

Tags : 

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

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

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

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

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

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

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

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

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

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

1. Change what you are working on to maximize value

Learn: Watch Agile Product Ownership in a nutshell

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

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

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

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

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

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

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

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

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

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


  • -

New ebook, Agile Advice

Tags : 

book coverMy 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.


  • -

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

Tags : 

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

onebillionincash

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

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

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

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

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

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

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

Cheers
Robin Dymond, CST

*Health and Human Services data

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


  • -

How Spotify Works. Agility with 1 product and 1200 people

Tags : 

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


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

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

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

Part 1 of How Spotify’s Engineering Culture Works


  • -

Expert Reviews of the Scaled Agile Framework (SAFe) Training

Tags : 

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.


  • -

The Agile Hardware Design Mindset.

Tags : 

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

PCB board design and layout.

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

Let’s examine each of these points:

Myth: Manufacturing a PCB takes a lot of time.

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

Myth: Manufacturing a PCB is costly.

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

Myth: We need to complete the full design.

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

Deploying iterative and Incremental hardware development.

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

Iterative and Incremental firmware with the hardware.

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

Using business value to drive product design.

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

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