Begin With: Why Do You Need To Build Software?

There are a many reasons why an organization needs to build and deliver software. Some examples might be:

  • Grow integrated strategic partnerships
  • Improve internal proprietary processes
  • Quality assurance and business intelligence
  • Build products and tools that customers will use directly

Taking the time to understand the “why” can help you determine how to structure a delivery team and establish long term plans. In many cases an organization may find it has multiple answers to the “why” and this could be a good indicator that a team for each might be a good idea.

Create Aligned Work Streams vs Functional Groups


Before we can dive into the 4 components that make a delivery team successful, we need to address team structure. For years many organizations structured software development teams by the “how” instead of “why”.  For example –  QA experts and engineers were divided into groups. I’m sure some of the thought process was to build competency within an organization. Unless you are offering those services directly to customers – your goals shouldn’t be building a stellar “QA” or “Engineering” team. You want a high performing “delivery” teams that just happen to be composed of individuals in these roles. Consider objective first, software creation second. Think diversity of perspectives – putting people with different skill-sets and roles together for a common goal will cultivate continuous improvement.

The 4 Components

I’m going to attempt to describe each component and then give examples of ways a team can implement each one. Understand that every organization and workstream may be different – so not all may apply.


Build

Build is traditionally measured by how well your organization can produce technology that can scale, can be maintained cost effectively, and functions consistently.  In addition to these considerations I would also include flexibility. A build team that understands how to work iteratively – applying the correct level of technology & effort to deliver what is necessary is key. The ability to produce quality software in a predictable way is the result of multiple aligned efforts.

Application Portfolio Management & Support:  In order to continue building you have to consider what has been built already. One mistake many organizations make is creating dedicated support teams that are not aligned with a work stream. The result is a disenfranchised team and a pile of technology that eats up resources. A team that doesn’t manage its portfolio will also run into serious tech debt issues – ultimately impacting its ability to deliver. Further Reading:  (TIME) Tolerate | Invest | Maintain | Eliminate

DevOps: In my mind the greatest contributor to effective delivery is the ability to ship code safely and effortlessly. Thinking back to days when I had to deal with 45 minute builds, complex manual deployment processes, and terrifying testing procedures – this is an easy one in my book. I also believe this is an enabler for organizations with on-prem technology that want to get to the cloud. Further Reading: State Of DevOps (Google)

Quality Assurance: This requires a role that specializes in regression and user acceptance testing. Some of this can also be automated but nothing replaces an individual with domain knowledge that can find bugs. The level of QA necessary for a work stream is dependent on the level of acceptable risk. Ex – financial or healthcare processing will need more QA that a startup still looking for product market fit. Further Reading: Software Testing Tactics

Software Development: An obvious component of build – a good development team is critical to executing.  Software craftsmanship concepts such as TDD and SOLID are game changers when attempting to deliver high quality software quickly.  Further Reading: SOLID | TDD

Learn

You must inform your build effort, otherwise you will produce technology that is of little value (meaningless). You do this by growing the collective knowledge of the team. It’s important to understand that one person or one role isn’t solely responsible for this on well functioning teams. Every member should have the freedom to contribute.

User Experience Research: This role is an absolute must for product focused work streams.  Creation of user personas, qualitative & quantitative research, and structured user interviews are all important if an organization wishes to build products that provide real value. This role also places a high emphasis on creating value by understanding the behaviors and needs of users. Further Reading: User Experience Definitions 

Business Analysis: While UX focuses on users, BA roles tend to focus on business and process.  The type of work stream again determines the importance of this role on the team. Business analysts also tend to retain and build domain knowledge. This can be critical as well if your work stream is heavy on complex business processes. Practices such as process mapping and requirements gathering are extremely valuable when dealing with complex workflows and business needs. Further Reading: 5 Whys  | MoSCoW


Technical Analysis & Design: Commonly misunderstood or ignored this role is a must have on teams that maintain and enhance large systems or a large number of applications. Sometimes domain knowledge lives within code and the only way to re-discover requires a deep dive into the code.  In most cases this needs to be an experienced developer who can translate code into requirements (or at minimum technical specifications). Some organizations attempt to avoid this by producing large volumes of documentation – in many cases it’s not a viable solution.  Further Reading: Using FDD Features

Promote

Once you build something you need to ensure that its value is understood by stakeholders and users. I consider this effort one of the 4 pillars because without it you don’t receive feedback or traction. Unused software is meaningless software – even if it “could” offer value. There is strong overlap in this area with general sales and marketing but this is outside the scope of “software delivery”.


Demos: One way you can promote internally is via “Demo Days”. Showing new functionality to stakeholders and team members creates conversations which generates internal feedback loops. This ensures that everyone understands the value. Also, this also offers an opportunity to team members who wish to build communication and speaking skills. Further Reading: How to Give a Great Agile/Scrum Sprint Demo

Roadmaps:  Communicating the direction of the team to the organization is important. Hopefully it can provide a source of excitement and inspiration for the entire organization. A well communicated roadmap in conjunction with a good company culture should result in aligned efforts and a shared vision.  Further Reading:  Department Of Product: Roadmaps

Customer Experience: Ensuring that customers can easily understand and utilize features the team has created – in conjunction with the offering as a whole ensures that engagement can scale as the product becomes more complex (and/or integrated).  I consider this “promotion” because creating a good customer experience is a form of promoting the underlying value provided by the platform.  Further Reading: User Experience vs. Customer Experience
 

Core

Now we get to the really fun part. Putting it all together. While the other 3 components can vary based on organizational structure and work stream needs – these items are non-negotiable if you wish to successfully deliver meaningful software.

Ownership:  Without strategic direction a team is very likely to focus on small items that don’t line up with larger objectives (although I do think it’s possible for teams to become aligned – a topic for another time). Decision makers need to be responsible for collecting information from all 3 components, weave in considerations from leadership, and set a course. Among the many decisions to be made lies the most critical – platform and feature prioritization.  Further Reading: A Stakeholder Proxy for Agile Teams

Continuous Improvement:  A team that wants to deliver meaningful software must strive to be better on both a team and individual level. The only way this works however is if the team defines and measures continuous improvement goals on its own. An autonomous team that has the freedom to test (and fail) in an effort to improve will produce consistently better results long term. Further Reading: RetroMat

Work Agreements: Informed by continuous improvement, this can include work visualization, code quality practices, ceremonies, definition of done, and other “contracts” among team members. The importance of mutually agreed upon expectations is it removes frustration from the day to day. A good example of this is user stories. A great format for collecting requirements and managing the work – but the real value is its ability to transfer knowledge among multiple team members and roles in a well understood format. Add the ability to visualize priority and progress and the team finds itself aligned. Also keep in mind, while the agreements may be rigid in definition your continuous improvement efforts should allow for them to change easily when necessary. Further Reading: Agile Meetings – Goals and Benefits | Kanban vs. Scrum

If you want to improve your ability to contribute to and drive the delivery of meaningful software I’d encourage you to follow along on this journey – sign up for my weekly newsletter.