Agile Primer for Cowboys and Hardware Folks

Agile primer
Image credit: VersionOne, Inc.

In today’s connected devices world, where every hardware product also runs or interacts with a significant amount of software, every product development person needs to know how to develop software. This can be a bit of a culture shock for hardware people, who are used to a different type of development process (stage-gate, anyone?).

The objective of this Agile Primer is to demystify Agile for people who don’t have a classical production software background, so that they can integrate elements of Agile into their cross functional project management methodologies. Also, software developers practicing the “Cowboy process” and experiencing growing pains might benefit from this primer as well.


In the bad old days, product development was a one way road. Product management spends a long time with customer research, market analysis, and requirements gathering, and they can take months to years to produce large documents (the market requirements document – MRD, the product requirements document – PRD, and the functional specifications). Once these things are defined, a software organization would then scope the work and go forth and conquer. The specs are never changed once they are set in stone.This is traditionally called the “Waterfall” process.

This method used to work well for very large scale programs which have a significant safety or security component which requires thorough documentation and a lengthy validation period (e.g. software that goes on a space shuttle, or software running on a life sustaining medical device), but in today’s competitive, fast paced world, it is increasingly a cause of program failure for the simple reason that it is too slow. By the time the specs are defined, the world has moved on and the specs have become irrelevant. If development followed the spec the product is guaranteed to fail; without an alternative means to capture requirements, development can end up chasing its tail.

Some software development organizations have embraced alternative methodologies like RUP (rational unified process) or AUP (agile unified process). These processes allow for the up front planning while making room for iterations. Detractors say they are still too slow and process heavy. What most people do today is Agile Development. The Agile philosophy values iterations and ability to react to changing market conditions over heavy documentation. The Agile manifesto goes thus:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more

Recall in waterall/RUP processes, there are large documents called MRD, PRD and functional specifications. These describe upcoming releases in terms of market requirements and a feature set but often fall short of describing customer use cases. Without proper engagement with customers, it is all too easy for the UI and development teams to develop features in a vacuum which don’t string together properly to support complete customer workflows or are inexplicable to end users.

In contrast, the primary form of documentation is the user story, which is a description of an action taken by the user from the user’s point of view. This format forces the PM, UX and Dev organizations to work together to define the next level of technical implementation detail and typically results in better solutions for end users. One thing that a lot of agile development organizations don’t do well is the strategy.

Since agile development is naturally very granular, it is easy to fall into the trap of incrementalism where progress is measured by user stories without consideration of the overall product strategy, roadmap or themes for each release. It is very important for product management not to lose the big picture – the upfront strategy work should still remain, to ensure that the overall product strategy when viewed over months or years make sense and meet the company’s strategy needs.

Key roles

The agile process assigns specific roles to individuals responsible for managing the process or contributing to development.

  • Product owner: this is typically a technical product manager who is very deep in the details of user stories, bug lists etc. If the PM is nontechnical, then the product owner role can be taken by a developer with customer focus or a UX designer.
  • Scrum master: this is typically a development lead who is responsible for running the scrums and doing general project management.
  • Team member: a developer who writes code. For web developers a lot of the front end developers double as the UX designer.
  • Stake holder: a user, manager, sales person, customer support person etc. who is impacted by the software being developed.

The above roles are the classical definitions, but in real life there are other roles that are not mentioned who are critical to the smooth operations of a software development organization.

  • Product Manager: the CEO of the product. Depending on the person’s training their focus may be strategic, technical, or marketing (see pragmatic marketing framework for details – link in references section). The best match for a PM working closely with a software organization is a technical PM, who can double as a product owner.
  • UX designer: a ux person responsible for the information architecture, interactive designer or graphic design (The IA and interactive designer are often the same person while the graphic designer is often a different person).
  • SQA engineer: for all but the most casual applications it is advisable to have a separate SQA function to do automated and manual black and white box testing.
  • DevOps engineer: If the team is large enough (e.g. 20+ developers) it is advisable to have a dedicated development operations engineer to take care of the build system, execute builds, maintain the continuous integration platform and issue tracking platform and what-not.

Key concepts

The top concepts that are used to organize work include:

  • Sprints: typically a 1-3 week duration which is a unit of work.
  • User stories: these describe actions the user take to achieve a specific objective when using the software.
  • Scrums: a daily 15 minute standup meeting for coordinating work, with a very prescriptive format:
    • The scrummaster goes around the room cueing each person to provide a status update
    • The status update is always in this format: what I did yesterday; what I will do today; what’s holding me up
    • Scrums should not have more than 10 people in it – if headcount >10 it is good to break it up into 2
  • Backlog: The list of userstories that are force ranked continuously – representing the known work that is planned
  • Burndown: A visualization of progress towards the sprint goals depicting work remaining over time
  • Sprint planning: At the start of each sprint the team will get together and plan the work for the sprint by allocating user stories that fit within 1 sprint for the people available to work on that sprint. Once planned, the sprint content should not change afterwards. The time spent in planning activities should not be more than 10% of the actual sprint time.
  • Retrospective: at the end of each sprint, the team will get together and look back on what worked, what didn’t work, and how they can improve on their process in the next sprint.

Release planning

On top of these incremental development sprints, there is a super-structure – the release cycle. With the exception of web software without SLAs, most software products or services ought to go through an SQA/final validation period prior to going live (more on this later). Then marketing will need to explain the release to customers, train sales, and sales will need to train their channels in a coordinated product launch activity. All this means that releases need to be planned and themed before development begins. A release usually goes through the following stages.

  • Release planning – come up with the theme of the release commensurate with the direction set forth by the product strategy/product roadmap. PM/UX/Dev collaborate on a high level estimate of rough scope and rough duration / ETA understanding things can change once you get into the details. Acceptance criteria for the release readiness review should be set at this point.
  • Development sprints – development goes into a metronomic sprint development cadence where something working/demonstrable is available at sprint end every 1-3 weeks. Properly run dev sprints should be integrated with UX and SQA.
  • SQA/stabilization – a branch is made from the working code and SQA tests and logs defects, which are prioritized, load balanced and allocated to developers by the team lead/scrum master/sofwtare manager.
  • Release – when the software meets acceptance criteria, it can be released to marketing/sales for marketing launch.

Interactions with UX, SQA and PM

Classic Agile is highly insular and development centric in mindset, as evidenced by the fact that all the original roles are effectively developer roles. To develop great software with a great user experience, great cross functional interaction is needed between 3 other groups: UX, SQA and Product Management. There are some inherent friction points, because there are natural cross dependencies.

  • Release planning via PM / Dev team lead / UX lead must precede all activities, yet in such an early stage, it is hard to estimate work since the stories may not be defined and definitely not all thought through. The fix is to swag everything and understand that the confidence level is low for the ETA (therefore: NEVER tell the outside world about the release date until you are almost ready to release the software).
  • UX v Dev: UX needs to get at least 1 sprint ahead of development, feature for feature, so development has designs to implement (unless the developer is also the designer which is the case in some organizations but not true in most heavily customer-facing orgs.)
  • Dev v SQA: SQA needs to be 1 sprint behind Dev so they are not testing a moving target all the time during development.

Thus, in an ideal world, the sprint breakdown would look like this.

  • SPRINT 0
    • UX works on feature set 1
  • SPRINT 1
    • UX works on feature set 2
    • Dev works on feature set 1 (using designs from UX)
  • SPRINT 2
    • UX works on feature set 3
    • Dev works on feature set 2 (using designs from UX)
    • SQA tests feature set 1

… etc

Getting Agile to play nice with embedded style deployments on custom hardware

If you look at what types of companies are successful in deploying Agile in the purest forms, you will almost always end up with companies doing web development. Web development has a very natural affinity to the Agile process because it is often possible to take a big project and break it down into small user stories, and it is also possible to invest in test-driven development (in which the unit test for new functionality is written prior to the feature itself), thereby streamlining the testing process and enabling very successful white box testing, and minimizing the time needed for final validation. Some companies (e.g. Hubspot) actually practice continuous deployment – they can push code to production servers several times a day.  They can afford to do so because they can always roll back a bad build.

For embedded style deployments, however, there is no such luxury. Imagine you are running the firmware development team for, say, Brother, who makes printers and all-in-one machines.  Do you expect the printer to work out of the box? Absolutely yes.  Will you get there without putting the code through a structured validation process? Absolutely not.

Generally, in cases where the quality of the code is mission critical to the end customer (E.g. if it has to do with medical devices, or with human safety, or some such) a good rule of thumb is to maintain a 2:1 ratio between development time and final validation time.  You can still practice agile development during the development phases, which will make you much more nimble and effective than if you practiced waterfall or RUP, but you will still need to go through a final validation period. That way you get the best of both worlds: the ability to turn on a dime that is afforded by the Agile sprint structure, and the quality assurance benefits from a final validation period.

One last thought. If you are deploying software on custom hardware, realize that hardware is new product development too.  The hardware platform itself may or may not be mature! When tracking down issues it becomes extra complicated when you don’t know if it is the hardware or the software that is at fault. In this case, don’t panic.  Form a tiger team with people from the hardware side and systematically and cross functionally dissect the problem until you find the root cause.  Software development cannot be siloed from hardware development in these types of integrated devices – cross functional collaboration is the only key to success.

Leave a Reply