How individual contributors add value to technology teams when not managing people

Building software products is a team sport, and there are many positions to play on any team. In software teams, technology leadership positions have evolved over the years from primarily people management to a combination of personnel and technology management.  It’s difficult for one person to fulfill these distinct responsibilities successfully; as a result, successful teams have split this role into two:  Engineering management is people management, and Staff development is focused on technology production. 

The success of the team is dependent on the people involved, and the understanding of the goals they need to achieve. The Engineering manager enables an understanding of these goals, enabling teammates to play their positions more effectively. This develops the person. 

The individual contributor isn’t the coach; they are more like the team captain and they show by example how to fulfil the responsibilities of the position. This brings other developers up to a higher level of quality development. The Staff developer moves the technology forward. While the specifics can vary from team to team, at their core, they must fulfill the fundamentals of: 

• Technical excellence, by example
• Predictability of delivery for stakeholders 
• Ensuring Architecture quality through collaboration on design and review 

Technical Excellence, by example

A staff developer must show technical excellence by example and how to move development forward with quality and velocity. This effort is not just building a feature, but engineering the feature so that it has the quality needed for the product to be successful in the market. 

Starting with the code and showing guidance and practices for maintainability and portability with pull requests that follow a declared set of quality attributes that guide quality code. What is quality code? Code that follows common conventions that the group has decided on. This is formatting, linting and type safety so the code in the product is something everyone can recognize. Remember that the code isn’t the developer’s code, it is company property and must be maintained responsibly so that any developer can work on it. Working through pull requests by making sure the collaborators can review and push the code to production in a common way. There will be unknowns to figure out, but it’s necessary sometimes to run into the dark room and light it up together.

https://jseller.blogspot.com/2020/03/packaging-code-for-development-and.html

https://jseller.blogspot.com/2023/06/maintainable-and-portable-codebases.html

Staff developer Improves predictability by reducing scope. 

Understanding the context to help build features for the user that are valuable. To move the product forward, understanding the impact of the decisions helps the predictability of the process and communication during design implementation

The smaller the better and output an implementation Epic to understand the definition of done for this enhancement. Work that implementation to production.  Use feature flags to enable this functionality to the user when releasing to the production environment

https://jseller.blogspot.com/2019/01/software-releases-are-lot-more-than-code.html

Ensures architecture quality and collaboration on the definition of that quality

Operationally the Staff developer ensures a high level of adherence to the quality attributes of the system. The functionality, does it have some understanding of the problem we are solving for the user? 

Collaborate on functionality, observability, and the tools and processes that enable easy maintenance of the product in production. Adhering to known standards establishes good practices and processes. 

https://jseller.blogspot.com/2019/01/feature-definition-with-quality-model.html

Does the solution have a coherent definition of the functionality and acceptance criteria? Staff developers know they can’t build the whole thing in one change, but able to break down the solution into smaller chunks and gain agreement on the smallest definition of done that shows the value

• https://jseller.blogspot.com/2023/06/effective-software-architecture-meetings.html

Evolving the architecture together

To support any functionality there will be changes to the architecture. Develop a strong culture of design through a standardized process of RFC (or ADR) review in the team. 

• system requirements map to unit tests so the understanding of the scope is clear. 
• build tests from the acceptance criteria for integration testing in the development and staging environment
• build sanity/smoke tests to validate this functionality in the production environment
• build observability, performance, security, and portability from these small changes, 
• Working with living specifications enables async collaboration. Keep these documents concise and to the point. 
• Good design ‘fits in’ to the system, use diagrams for containers, and components. that are new or changes
• https://jseller.blogspot.com/2023/06/consistent-software-design-enables.html
• https://jseller.blogspot.com/2020/02/communicating-software-architecture.html

Wrap-up

Staff development brings an awareness of the product and company’s goals to technical development. This ensures the teammates can align on the architecture and collaborate at scale to deliver a quality product. This direction, and most importantly, the collaboration with the team members, ensures that the product produced can fulfill the goals of the company’s place in the market.

Effective Software Architecture meetings

For an effective architecture strategy to develop; there needs to be some alignment when meeting together. In meetings with no agenda or focus it can seem to be a waste of time. It is. if the meeting invite is “we are going to brainstorm on everything” then meeting fatigue will set in and participants will have less engagement.

Its also essential to be clear that this isn’t a status meeting; the status is on the board, backlog and roadmap. Those are the outcomes of these meetings. The status should be visible without a meeting.

The common goal/output of the meeting is some decision on how to move forward with alignment of the participants. To set the theme and get an output of the technical meeting to be an effective one; its essential to understand the context of the meeting, and the participants.

Problems and Solutions

How to enable problem solving and know the valuable problem is being addressed? How to enable decision making so that we have a solution to work with and con move the understanding of the problem and our technical solution forward. Communication is a lot of listening and focusing on context

Focus on Context and Outputs

Meetings and the audience

For any meetings you have; take a moment to understand the Goal of the meeting, and from that it should be understood what you are working with here. Its also nice for any participants to know the context if they have some topics to bring up, or to be a listener in the background; or not participate at all

Discovery

Product discovery meetings are key to understanding user problems for features; and the deeper understanding of the technical constraints for this new feature.

These could be from ideas from business, dev, product, or triaged from a customer issue or suggestion; but the rationale for adding or modifying the architecture should be rooted from something that creates value in the product.

These output to the Roadmap level, product or technical; and sometimes need a prototype or more investigation to qualify the actual goal (and motivation).

Outputs

1. Valuable problems
2. Feature value
3. Market direction
4. Business Impact

Audience

• Product
• Sales
• Support
• Development
• QA

Planning

You have discovered the valuable problems and understood the value solving that problem will bring. Now its time to plan the technical solution; to creating the requirements and design for system features. 

User story mapping is really helpful as this stage as it uncovers the quality attributes to support this new feature. Also at this time trade-offs are made, so be mindful of any debt you are going to put on the books. Debt is useful, but like any debt it will overwhelm you if not kept in check.

As you go a long, you will learn more, so this meeting works well as a regularly scheduled meeting. In agile this is usually a "Backlog grooming"

Output

• Backlog items for functionality
• Technical spec
• Architecture Decision Records (ADR)

Audience

• Development
• QA
• Product

Implementation

The backlog has items for the functionality and the tech spec has the designs and decisions made. Lets build this thing! This is usually called a sprint onboarding, a kick-off meeting and gets the project people involved. This is when estimation can become possible with the details of what is being made now down on paper.

Outputs

• implementation Epics for some definition of done
• interfaces for implementation
• how requirements build acceptance criteria

Audience

• Devs
• QA
• project managers
• product managers

Release

Are we releasing work to support a feature, or is this a new one? Release meetings can take on many forms. and again depends on the context. A demo is an internal release and what is in that demo can be used to form the external release. For the technical architecture, the items can be lost in favour of the functional product notes; but its important to keep the architecture in-step with the release numbers you put on the deliverable

Version the architecture with the release

Output

• in the release notes, link to latest requirements that created that version
• Link docs describing features and acceptance criteria
• diagrams of structure
• mockups of UI and flows

Audience

• product
• QA
• devs
• devops
• Support
• Sales

When the meetings happen

There can be a tendency to get people involved, but having the wrong people can really hurt the output. Keep the focus to the group affected. For most architecture decisions its usually the team making the feature, when they plan to do the work. 

For architecture decisions on cross cutting quality attributes (Usability, Security, Performance, etc) its important to have a working group that focuses on setting the policy (a good checklist) for the functional features to get built on

Conclusion

When making the context clear and involving the relevant participants; architecture meetings can be a reliable way to output relevant decisions. Its essential to know What we are making so we can figure out how we make it and when it happens.

By taking a moment to understand the context and the problem to be addresses; the actual people that are needed to participate will become clearer and the chances of a meaningful solution will increase.

From Big Idea to Product

This is a story of a big idea. It's where a group of people who want to make technology that can turn into a business and generate money and thus, feed people and their dependents. In this story the participants have worked in technology start-ups; so they have got past the grand ideas of getting rich quick, and now just want to make a living with a business they can call their own.
We have all read about this happening, so lets go through an exercise of making it happen! In this story I work with my trusted business partner Liz. She is hyper organized and good at business. I am neither of those, but can make software; so we make a good pair.

Liz phoned me up the other day...
"I met someone that works as a cashier, and they have to carry around this cash register all the time. The shop they work in want to expand, but these registers are expensive. Thing is, all it does is add some numbers and print out a receipt. I thought, a software app could do that; and it would be easier for them to use their phone instead of the big register. Also, if it works and is cheap to buy, they would use that instead of the register."

Then I thought: don't all stores have this problem? If we make a 'mobile register', then we could disrupt this entire cash register space!

Understanding the problem is the start of solving it

Ok, so from that we have some things forming up about the product definition; but it's clear we need to know more about this opportunity before we start making anything. What's the value to the user, and the buyer? Is this a big market or small, and who would pay for this? If they would, how much would they pay?

Using lean canvas or the venture process, we can go deeper on the understanding of the possible opportunity.

Our Hypothesis: People buy stuff, so the need to cash them out seems pretty real and constant. If the register is expensive and we can build a cheaper one; then small companies would buy them to save money. presumably any company would for the same reasons.

My response to Liz: "Ok, this seems feasible at a glance, but need to know more. Let's find some prospects and see if this could work."
Liz went back to her original retail friend Chris, and asked if he would like a cash register on his phone, instead of carrying the old clunky one around. 'Sounds great!' Chris said.

• This issue with this 'ask' is that Liz was immediately selling Chris on the solution, and that sounds good. What is Chris going to say? "no thanks, I love ol' clunky!".

Perhaps a better approach would be investigate why Chris would trade his old machine for the phone or why not. Asking why would get to the problem at hand, and a good way of finding that out is investigating what they do now to solve their cash-out problem.

What do they do now?

If the problem is key, and the solution is valuable, the prospect is doing that job in some way. What we are hoping is that their methods have pain that they want to get rid of, and see our solution as a way to get there.

So, what does Chris do now?

1. Carry around clunky, its heavy.

2. Clunky adds numbers, but I need to look up the currency conversion in the daily currency table and the tax rate of the buyer. Mary wants the totals in CDN dollars.

Ok, who is Mary?

"Mary is the manager of the store. I need to send her the totals when I'm done with a shift so she knows the totals."

It turns out Mary the Manager is a persona we need to care about; since it's Chris' job to report totals to Mary. Lets talk to Mary about her role and these 'Totals'.
Mary responds with:

'Ya, I need to settle up every day and send sales totals to my owner, and I also need the totals to get my inventory status'

This info is gold! Mary need 2 outputs from the register experience. The sales totals of the shift, and the amounts sold so she knows what inventory is left, so she can order more or not, and see what is selling.

Now we have 2 Personas; a User (Chris) and a Manager (Mary), and there was also mention of the Owner. We have to care about Mary since correct reporting from Chris its a measure of doing his job correctly. If we make Chris a success in Mary's eyes; he will use our tool. If Mary is able to provide great reporting to the Owner, then she is a success, and she will use our tool. So, in reality, we need to make the tool for the Owner of the store, and then Mary, and finally Chris. This may seem counter-intuitive since Chris is the one using the tool most often, but its the value that the tool is able to generate that pays for it, and the Owner is the persona that needs the convincing.

Personas and Problems

• Chris the Cashier - adding numbers, calculating/adding taxes, converting currency, reporting sales to Manager. time to cash-out customer
• Mary the Manager - calculating sales, reporting on sales and inventory used, reporting to Owner
• Sue the Owner - needs accurate reporting of inventory and sales to determine health of the store.

Ok, this seems to be making more sense; but one big question still needs to be answered. Who is going to buy the product?
Would Chris pay out of his pocket? Would Mary expense it for Chris? Does the Owner need to OK that purchase, or does the Owner make all the decision making on the purchase? At this point it could seem like a good idea to pitch the Owner to buy the product, and convince them that the managers and clerks in their stores need mobileCashier (we just decided to call it that).

This is probably too early to directly sell to the Owner; as the first contact from the Owner's point of view is getting sold on something they haven't heard of.

User Personas influence Buyer Personas

What would be more influential is to have Mary tell the owner that they are trying a new product that will save time and money. If you were the owner, what would you listen to? If Mary sees value in it, then she will pitch for it, and if Chris is making more sales because of the efficiency gains from the app, then he will tell Mary about it.

Persona Key Problems

So, this is only going to work if Mary proves to the Owner that mobileRegister saves time and money, and thus increases sales throughput. From this, we can ascertain that a Key Problem for the Manager Persona is reporting on sales and inventory. If we don't build that, Mary won't see the value. But wait, you are still making Chris carry around the old register? Sure, but the sales and inventory report is what is really needed in the end. We can address this key problem by making sure when Chris uses the app; the data generated ends up in the reports to Mary. It might even be enough for the MVP to forget about the manual currency and tax calculation and concentrate on the report for Manager Mary.

Domain Problems

Regardless of the users involved, there are rules about the domain of cash registers that we need to satisfy, and these will become requirements of our solution.

• Numbers arithmetic of adding, getting percentages and totals.
• Currency - this changes, so how do we get the latest exchange rates? How accurate does that have to be? Daily, Hourly?
• Taxes - this changes, but only annually. How do we get updates on the tax rules for any country that the user is in? How often will we sync our rates with the reference. What is that reference?

Checkpoint for Market-Product fit

We don't have anything resembling a product at the moment because we are still figuring out the key problems for the Domain and the Users in the Market. What we are trying to identify is what key problems that the user will need, and need so much that they, or the persona identified.

Go for a v1?

How far does this research go before starting to build? This is a tough nugget. You need to know you have a Market that has users and money to pay for a possible solution. We could spend more time analyzing this, but it might be more effective to build a simple version so we can go back to our prospects with something that is showing that we can solve their problem. Otherwise we could tire them out with our research questions.
You might find users that are totally passionate about what they do; but most people are there to get their job done.
This set of problems, personas and jobs to be done is a key deliverable for understanding the market and how our solution is effective at solving key problems. This understanding will evolve over time as we learn more, so it's never done, but there seems to be enough there for our current needs. We really believe there is a need. There is, but perhaps the point of sale space is a bit crowded (it is), but we think we are going to build a better mousetrap.

From this point, both Liz and I have our current mission.
I need to

• start on a possible architecture that will allow the user to do the cash register thing over the web on a phone
• do reporting, this sounds like a desktop spreadsheet thing
• find out about the data needed for currency and taxes, can I easily import this, and can it be automated

Liz need to understand the basics of the business

• Cost of getting a customer and more customers
• Understanding the jobs to be done, and how big is the possible market of people that do this?
• A basic forecast to understand what can be sold, for how much, and how many customers are needed to pay the two of us

Time to make something

We think we are onto something here, so we are going to build what we consider to be a MVP to test out this hypothesis and see the results. How do we do this? We have a good idea of what is required, but its still in a very informal format. We need to understand how the user is going to use our solution, and what problems from the domain need to be solved to show that the product has value.
Understanding these Problems will form our Strategy for building this solution, and the company that surrounds it. It's a key deliverable, for sure.

Lets go for it

We are going to take the next step. We do this by formalizing the behavior of the User in Stories, and conversely, understanding the Requirements of the solution to make it all happen.

• User experience is a combination of user stories. we validate the story with Acceptance Criteria. 
• Domain Rules need to be formalized so they can be implemented.

 but that will come in a following post... till next time!

The W5 of developing software products

This post is from a set of slides I did in a presentation to a group of product managers. The title of the talk was "working effectively with developers"; and the general theme was to explain development terms such as "technical debt" and "re-factoring".

Once we started talking out what these terms meant and how they fit into a development process; a larger picture of what software product development actually 'is' started to emerge. So, to break this very large subject down into a manageable presentation I used the tactic of investigative journalism, and focused on how the 'who', 'why', 'what', 'where', 'when' and 'how' of developing products.

This is from a developer point of view, but drawn from experience of being both a developer and a product manager. When starting a software company from scratch, you really need to perform the duties of these roles at the same time, and you realize that the goals of both of these roles are the same:

Observation: At the end of the day the main goal is to solve a user’s problem with your technology; and they will pay you for it. With that money you eat, party, and continue the cycle again.

What is product management?

When talking to many of my product manager and development colleagues: one theme started to emerge pretty quickly. The definition of what "it is" was different with every conversation, and when referencing job descriptions that were titled "Product Manager" the roles and responsibilities outlined seemed to diverge just as much.

This role, which didn't really exist 20 years ago, is still finding its own definition. That definition is different in every group (company/team) producing software. Now, I see it as a catch-all to manage:

• a Product (what?)
• a Customer (who and why?)
• a Process to make it (how)
• the Schedule to deliver a solution (when)
• a Team to make the solution (who again? yikes)

This sounds like everything! So, to do everything it might be a good idea to separate the Roles and Responsibilities to understand what gets done, by who, and when. Be sure to have an in-depth conversation to outline these responsibilities (and expectations) when taking on a Product manager job. 

The Product Developer

From the developer’s point of view, there has been an equal amount of change in what a 'developer' is. In the most fundamental view, a technology developer has to perform 3 basic functions. There needs to be a design of a system, the implementation of a system, and the validation of the systems function and utility.

In isolation, with well defined design, this is possible in many technologies. Buildings are designed with blueprints, and built with construction methods, and validated with engineering. That works in civil technology (buildings, cars, trains), but for software engineering the methods are different. 

Observation: Skill vary tremendously when talking about one person doing this, and software lacks formal education and certification on what it means to be an 'architect', 'engineer' or builder (programmer). This hasn't been standardized; so for a non-technical person to hire a 'developer' its a very murky understanding of what a person is capable of. 

So, lets investigate....

The order of priority on the 'who', 'why', 'what', 'where', 'when' and 'how' matters greatly, but it all has to get done. Things differ in the type of company it is. Is it product driven or project driven? If you are selling hours as a consultant the accounting of hours and the estimation of effort take on greater importance. If this is a product then the customer relationship and Domain expertise take on a greater importance than the schedule. It really depends on what you are getting paid for.

In the view of the product manager, I believe the order of priority should be “Who”, then “Why” and the rest in random order. If those first two are taken care of, many parts of the what, how and when fall into place. This is probably an over-simplification, but I really want to state the importance of the Who and Why in the realm of the product managers priorities.

Why we build products

This is fundamentally the main purpose of product management. Understanding why a customer needs what you are building. They need to solve their problem, and in using your product they want to solve it in a more effective way then they are currently doing it.

How to do this effectively? Understand the Customer and their Domain, understand what their job is, what is the actual outputs are and why some outputs are more important than others. This Domain modelling is extremely important in a product driven company.

Stakeholder are everywhere! The customer, their boss, your boss, your team-mates and their boss. Everyone has an interest that all this goes well. The priority of who gets attention can get lost in a busy day, but in the end, the customer should win all debates

Observation: In a software company, you will work with smart people, and those people will have opinions (hopefully). This is a good problem to have, but it can lead to ‘analysis paralysis’ in figuring out what to do next. Use the Customers point of view as a unifying force. Create your personas and outline their problems, name them and use them to put light on what’s important. We all have opinions, but the customers opinion actually pays the bills. 

What we are building: a technology

You can build buildings, cars or software, but the same fundamentals of Utility, Structure and Beauty apply to successful pieces of technology. It has to work, it has to solve a problem, and even better it has to feel good doing it.

• Functionality – solves problems, or doesn’t
• Structure – works great, or falls apart
• Usability – feels great to use, or not

Observation: Functionality and a little Usability can work even if structure isn’t great. People love Ferraris even though they break down, and people loved Twitter when they kept getting the 'fail whale' screen. Despite the structural issues, the functionality and usability was there.

For architecture nerds out there, this is the fundamental pattern of architecture known as the Vitruvian Triad. It holds up as a valuable pattern even if it was defined 2000 years ago. 

For Software, we run into a bit of an issue here. Software isn’t physical, it needs hardware, and the user only sees about 10-15% of the technology. I call this the ‘Iceberg effect’; since the user only interacts with the UI and doesn’t (and shouldn’t) be exposed to the inner workings of what is making diagram change when a button is clicked.

‘Tech Debt’

So, the term ‘tech-debt’ seems to strike fear in the business crowd, and for this developer its hard to understand why. Businesses (especially start-ups) don’t seem afraid of debt at all, and sometimes leverage the entire perceived value of the company for funding.

What is the current state of your technical balance sheet? You have assets if users are using features in your system, and you may have taken on debt to create them.

How does tech debt happen? Feature complexity is fun and easy to make when you ignore the costs. Same way that its fun to make dinner and not do the dishes

1. Keep a Source of truth on assets (tested requirements), and understand the debt incurred to make them.
2.  Pay off a little debt each release. Improve the Usability, Performance, Security, Observe-ability, Portability and Maintainability of your system.

Observation: Debt can be very useful, but it needs to be managed; or the complexity of managing debt will overwhelm you.

How to build products

Process and culture have the greatest effect on product quality. its a people issue. Ad-hoc process makes ad-hoc products and the user can tell.

Earlier on the roles to build software were somewhat defined: The Business Analyst modeled the domain of the customer, an Architect created a model to reflect that Domain, and Engineers and Programmers implemented that model. 

This was seen as a 'waterfall process' and while that worked for well defined and small products, things really fell apart in the larger products. Why? its because the understanding of what is being built changes over time, and that directly relates to the requirements of the system being built. Once the requirements become fuzzy, or not well understood, its really up to the mind of the implementer to get it 'right'. 

Observation: This phenomenon has been described as 'changing requirements' but the reality is that the requirements of what is needed don't really change; you and your teams understanding of what the requirements change over time. In the language of developers: you re-factor your definition of the requirements as you learn more about them.

How about that mock-up?

From my angle, a detailed mock-up is helpful, but you seem to want a lot more. A UI mock-up is like defining what a room looks like when you want a house. What really matters is the experience using it; and I see this getting better quickly with design process and (CX, UX)

Observation: Define Done to have a chance at finishing (or actually estimating work)

Good requirements force simplifying through testing. You need requirements to define, build and test and software

Releasing

Observation: You will learn the most about your product, team and process when you release.

Plan and be strategic all you like about the future; what you have today has the greatest effect on your success.

• version everything, its the last version not the date that matters
•  shipping to customer isn't done. reviewing and cleaning up is done.
• release through the company to get to the customer. This allows collective knowledge to be set to the new reality with every release 

Build planned work, and respond to requests on different boards. Use a feature driven process to build new features, this is something you can plan. Don’t bother trying to plan and estimate bugs, just use a different mechanism to deal with it. 

Who is building the product?

Try to use small teams for features and working groups for cross-functional items. The same group of people can work on many different teams. They do anyway, so just put some structure around it

• Meet and measure on outcomes, and only measure things that can’t talk. People talk, so talk to them and don’t try to apply metrics to their output. This builds communication, collaboration, trust, and respect.

Observation: Separate support requests and new feature development

If you are injecting work into your sprint, then there is very little value to any planning and estimation.

Kanban is great for support work and random requests. FDD, XP when used with Scrum can work for feature development (if emphasis is on requirements, not estimations)

Wrap it Up!

1. Priority is Who/Why
1. Build around customer problems
2. Customer development never stops, close the loop with customer validation.
3. Domain knowledge is more important than technical knowledge
2. What
1. Useful, Functional, and Usable will win
2. Beware of the ‘iceburg’ effect; it all has to get to get done.
3. Continually remove complexity, don't allow debt to overwhelm you. Complexity of your own creation is the real enemy.
3. When
1. Define what ‘done’ is to have any chance at correct estimates
1.  Done is finishing the dishes, not just serving dinner.
2. Less is more, slower is faster
4. How
1. Close Loops. If the issue originated with a customer, it's not done until the customer is happy with the solution.
2. Realistic requirements, not just UI mock-ups
3. Version everything and make smaller maps into the future
4. Involve Developers early and over communicate, as collective ownership really works.

Scrum, XP, FDD or Kanban? Use all of them!

There are lots of terms in the agile development world; its clear that we still figuring out the best way to make software. Here I illustrate the use of software development methodologies and what I have seen work in past projects. A lot depends on the project, the people available, and what the end goal is. What my intention is to illustrate that one process or methodology isn't the answer; but instead the most effective process depends on your situation. Its the same as using a screwdriver with nails, or a hammer with screws. Be pragmatic and use the tool that is appropriate for the job at hand. The main goals is the same: create quality technology.

Scrum time

How do we go about doing this? Let's firstly understand how Scrum can be used for organizing how people work together to build both projects and products. Scrum can be used to build anything; a bird house, a home renovation, car repair, and software. It's got nothing to do with the actual technology and everything to do with organizing the group of people doing it.

It can work to realize and understand some fundamentals of how we are doing any of these things:

• where am I in building this?
• what am I trying to accomplish today?
• what are the dependencies that I need to get that done?
• what is preventing me to getting this done?

Scrum the Bad

Scrum can work, but too often its miss-used; and becomes a tracker of time sheets and velocity at the expense of the product the team is actually making. Care about adding value to the product, as no customer is paying the company for time-sheets or velocity. These metrics just don't matter in the end.

Dependencies

For someone managing this process, those last two points are everything. If some piece of work is dependent on other items getting done, the job is to make sure those dependencies are in order and getting done; and if those items are blocked in any way.
In our home reno project; a plumber may be ready to install the bathtub, but to install it the materials need to be there(pipes and a bathtub). So the buying the tub and transporting from the store to the house is a dependency.
For software, its could be a button on the UI that submits a form; you could have your UI developer create that, but if the server API doesn't exist and the logic isn't in place to save the value in the database; then that UI developer is blocked. Ideally these dependencies are in place by the time that front end work starts.

So if Scrum is a general way to organize people, then it needs to be used in conjunction with a methodology that actually builds the technology. These are when terms like XP, FDD, Spiral come in. So, when talking about Scrum, it's really Scrum/XP or Scrum/FDD, or Scrum/RandomConversation. Only with that combination you can have a chance of starting and stopping a project; Scrum helps you organize the participants of a project; but you need a definition of starting and ending. Is Random Conversation a process? Not officially, but many organizations use it!

Product or Project?

Firstly, what is the context of the effort? is it a one-off project for a customer, or a scheduled release that adds to a product? For a one off project you have constraints of time, since you are getting paid based on the time spent and when the project is over there is no more development.
For a product, the constraints are the features in the product. So the measure of success is the amount of value you add to the product, and how it sets you up for the next release. For the sake of analogy; its more like continuously growing a garden that produces vegetables than it is getting one plant growing and produce one vegetable that you give to the person asking for it.

Product

• increased importance of maintainability since you have to live with this code for the long term. You have the opportunity to get it right over time over a number of releases, but you have to deliver enough value so the product can be used today.
• High need for innovation as your effort is trying to add value to a product that your competitors don't have. What is the differentiator in what you are making compared to the competition?

Project

This is something that is budgeted with money, so it's a time and materials type of effort. The client is really just wanting a working tool that solves a single problem; so the need for innovation and invention generally isn't part of this. Its important to use established technology and process so that the project has a measure of predictability. This is essential. If the project ends with the technology unfinished, who is going to pay for the remaining time to complete it?

• you have one chance to get it right, so there is an increased importance in requirements and design, and only building what you have time to do. 

How do to this?

Product

If you are making a product that has no customers, then you are adding features to get to a first version that you can release and get on the road of paying customers. This is where the concepts of MVP and Definition of Done apply. What is the simplest version of the product that fulfills the users goals and solves a real problem? For this, using Scrum/FDD or Scrum/XP has been very effective to constantly iterating to get you to that first release.

What happens after that first release? You need to keep iterating on the product to increase its value for the next release, but you also have customers using it, so you need to respond to them and fix their issues (or not).
For this, split your effort accordingly.

1. Continue to use the Scrum/whatevermethodology you used to get there, and use the same sprint cadence with people dedicated to that process. This work can be planned, you are in control of how much you take on, how much innovation is attempted and what you are happy with to release.
2. Use Kanban to organize the unplanned work. As issues come in, have someone dedicated to managing this so that the customer gets a response, and the learnings from that make it as inputs to the next sprint. It may be best to have someone dedicated to support during each sprint so the other members aren't interrupted; but rotate this position as it becomes a bit of a grind)

DO NOT combined planned and unplanned work in the same process; you will end up doing neither well. 

Project

You are making technology to a specification, and that specification needs to be understood and agreed to by the customer and the builders. Getting this correct will make or break your project; so take time to get this right, and get it done. Using iterations during this phase should involve the customer and builder directly, so it's intensive in a people participation aspect, but vital that the expectations and assumptions aren't left to interpretation at the end.

Depending on the project, a number of methodologies are useful here. Waterfall can work here, and the software may be part of a larger effort, so it's important to use a similar overall methodology for the whole project. This is also about predictability; so invention isn't really welcome here, and using established technology is necessary. This may seem less fun at first, but going over time and having to work for free to fulfill the expectations that were agreed upon at the start is a whole lot less fun.

Wrap it up

For Projects

1. Use established technologies (even if they feel old-school, the client probably isn't paying for innovation) 
2. Invest time in getting the specification correct, and set expectations for further changes. (Jobs to be Done, and Domain modelling)
3. Aggressively remove work if its not needed
4. Identify and resolve dependencies and understand whats needed 

For Products

1. Use Scrum with a methodology to plan and execute feature sprints. (Personas, Jobs to be Done, Quality Model)
2. Use Kanban to organize unplanned work so feature work isn't interrupted and customer requests are addressed.
3. Review each sprint to ensure each release is better than the last.
4. Innovate and add value so that the product is needed by its users. This is a process that lasts as long as your product is successful; so foster a culture of continuous improvement to get better over time.

It can be done! Projects are similar regardless of the technology; the client needs something to spec since the time and money is finite. So if its a home renovation or a website; use established tech and keep expectations realistic. For projects, you need to continuously add value while being responsive. Doing either well isn't easy, but it can be done by sticking to some sound fundamentals.

Feature Definition with Architecture Quality Attributes

Defining all that goes into a feature can sometimes stop at the functionality and not take into account the various system attributes that combine to make the feature actually successful for the user. Attributes like Usability, Performance and Security add to or take away from the user experience; so understanding them as a whole is essential.

This post outlines the usage of a Quality Model that takes into account the functional and cross-functional features to provide a template that can be used as a definition of done.

Definition of Done

The quality model is really useful for understanding the scope of what needs to be done for a single feature or a theme of many features together. The application you are building is just a collection of features that work together, and how they work together is what is ultimately how the user experiences the set of features. How fast, how secure, how easy they are to use is what is key. these attributes are sometimes referred to as 'cross-functional' as they affect all functionality in the system. Also the term 'non-functional' is sometimes used, but seems like a miss-leading term. They all do something; and it's hard to convey the importance of working on something that is 'non-functional'.

Where are these defined in working?

These constraints are sometimes included in issues or explained in a specification. It's important to be consistent, and treat these as the requirements they are. So, to that end, use acceptance criteria from the domain requirements to outline the compliance targets for the quality requirements. 

This is applicable from the large to the small; from Product Architecture to Application Architecture to designing a single Feature. This template can be used to fix a bug, define a feature, or an entire product. These constraints provide the definition of done, or feature completeness.

Are you ever done the product? Hopefully not! The quality model give you a high-level glimpse of what it does today. This combines the attributes of the user facing functionality with everything around it; so it provides a much clearer picture of what is required to get that feature to a done state.

in its simplest version, its the basic release of any software.
Functionality: By Theme, use domain research
Usability: Goals and Experience
Performance: general feel and response times
Portability: Dev, staging, production
Serviceability: Observable logging, execptions, query times, dependency health and status.

• Functional

• Business/ Human facing attributes to satisfy the business rules/problem domain.
• Match Personas/Jobs to be done with the Features that get their job done.
• Domain requirements from subject matter expert
• The Business value attributes that satisfy the business rules/problem domain. A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.
• Suitability
• Are there relevant business requirements?
• Accuracy
• Is the data shown to the user accurate?
• Compliance
• Are there rules/regulations constraining the functionality? are these known and declared?

• Usable 

• Is the system usable without a lot of training and previous knowledge? How intuitive are the controls and workflow? How does the User Interface 'look and feel'? This is the domain of user experience and has 
• How does the app match the job workflow? Is it similar and intuitive as to what I would do?
• get jtbd matching key problem. set requirements, fulfil solution
• This is the 'user interface', the 'look and feel'. For print and publications, this is called the 'design'. In software, this is the 'aesthetic design' and is really the tip of the iceberg. You only see about 15-20% of a software system, but its a very important part. Its has to be a comfortable place to get things done efficiently.
• Survey users
• UI/UX, HCI research (human computer interaction)
• Accessibility - the application is a web application, so it needs to be accessible from common browsers and not just desktop browsers, but tablets and phones.
• How intuitive are the controls and workflow?
• Is the system usable without a lot of training and previous knowledge?
• How does the User Interface 'look and feel'?
• Usability Compliance
• Accessibility requirements could be legally required.

• Configurable

• Configuration for: System (Dependencies), Product (Features), User (Permissions)
• properties for environment - networking, logging, dependencies
• properties for domain - domain rules, constraints
• properties for product - feature flags
• Permissions: 
• permissions seem to be the same as feature flags, but they are actually dependent on them. Permissions depend on Role in the system. Features depend on the product. Enabling a feature is decided before determining if a particular user has access

• Performance
• This is a measure of how responsive a system is. is it fast? and what does that mean? Do thing take a long time to load, or do some searches take a long time to run? When making a system that does a lot of things, its an equally or larger challenge to make the system do those things in a timely manner.
• instrument the system, know how long what takes. ask during usability reviews
• Does it use acceptable amount of memory and does the use of the memory scale linearly with more usage?
• Set targets to start
• page loads in 3 second response
• data ingestion speed
• high latent sources: 3 days
• medium latent sources: 4 hours
• low latent sources: 10 seconds

• Security 
• If a user is going to hand over their data, whether its their personal details or business information they don't want to have to worry about the safety of that data. They don't want their account hacked, or have issues where their confidence in the systems integrity comes into question. Its comes down to Trust
• define a security policy, implement threat mitigation, audit system regularly.
• Review security aspects of new features, review operational security issues and review results of security testing for Authentication (Identity) and Authorization (Roles and Permissions)
• No unauthenticated access to client specific data
• Questions:
• Is there private user data in the system?
• How can the different roles access the system?
• Is it deployed in a secure environment? (Asses the network security and use of standardized technologies)
• Is the data persisted to a secure environment?
• Is there any secure data in logs or other outputs?

• Maintainable 
• To be able to work on the system with others the code and artifacts need to versioned and the operator needs to be able to quickly diagnose issues. The code base needs to be maintainable to add features without breaking existing functionality
• Source code should be written in a manner that is consistent, readable, simple in design, and easy to debug. A set of attributes that bear on the effort needed to make specified modifications.
• Can a user other than the developer run the system? Are the tools to do that useable and coherent?
• Source code should be written to facilitate test-ability.
• Does the implementation follow the intention of the design?
• is there a design?
• The design of reusable components is encouraged. Component reuse can eliminate redundant development and test activities (i.e. reduce costs).
• Does the code comply to a code standard?
• What amount of the system can be verified with tests?
• How many of those tests pass?

• Extensible
• Requirements are expected to evolve over the life of a product. Thus, a system should be developed in an extensible manner (i.e. perturbations in requirements may be managed through local extensions rather than wholesale modifications).
• Can you change the functionality for future use? Is there a common coding standard
• Can similar functionality be implemented with the same component?

• Observability/Serviceability
• While the system is running, are issues easy to diagnose? If something goes wrong, will someone know immediately? How is it monitored?
• Can a user other than the developer run and configure the system?
• Are the tools to do that usable and coherent?
• Can you change the functionality without rebuilding the application, and can you add to it later
• Observability capabilities should include:
• on-demand query of all systems go
• real time alert of subsystem failure
• ability to see errors, warnings and info messages

• Availability/Reliability 
• The system needs to be able to run for long periods of time without degradation. Memory usage and resource allocations need to be sustainable and system loads predictable.
• Reliability Compliance
• Is there a declared/contracted availability?
• Does it run and not degrade over time?
• Deployment Execution.
• How do you know when deployment is done?
• Are the steps to deploy clearly explained and documented?

• Portability 
• The system needs to adhere to standards so that it will be able to run on publicly available 'clouds' without modification. There are many candidates and an agile project cannot be locked into a single vendor relationship.
• Source code should be portable (i.e. not compiler or linker dependent). A set of attributes that bear on the ability of software to be transferred from one environment to another.
• continuous integration and automated deployment help here
• Will the application run on other environments? Other operating systems and networks? Have a developer version and testing version with recent data. 
• Does the application run on the target environment? Does it only work on the development environment? Is there a process for incident and change management? (ITIL standards are a good start here)

• Interoperability 

• Does it play well with other systems?
• using standard protocols?
• Can the system survive with its dependencies in a bad state?
• Are all the dependencies identified? (Assess network connections and other dependency couplings)

• Efficiency/Scale-ability 
• The relationship between the level of performance of the software and the amount of resources used, under stated conditions.
• Scaling. Does it use acceptable amount of memory and does the use of the memory scale linearly with more usage?
• Can the application share resources, or does it need its own machine/cluster?
• Time Behavior, Resource Utilization, Resource Allocation
• Under what conditions does the application leak memory? hog cpu cycles?
• Efficiency Compliance
• What is the current performance benchmark? what's the next target?

Application Architecture in the Large

The System satisfies the requirements through its various features. Use the quality model for a specific feature, or a collection of features within a product.

Understand technical debt from a high level. It's quality debt, but like the financials debt can be useful to get you to the goal; it just needs to be managed effectively.

Integrating in the process
All these points encompasses Quality Standards that need to be validated by Quality Engineering

Sign-off
For each quality requirement listed below, get sign-off from owner as part of the architecture review. An understanding of the current benchmark and achievable targets will properly frame expectations.

• Functionality - Product Manager using backlog stories/acceptance criteria
• Security - Sec Audit using security guidelines/standards
• Usability - UI/UX - using usability standards
• Performance - Performance Engineering using reliability/availability standards
• Maintainability - Tech Lead using Code Guidelines/Standards
• Portability - Operations using deploy and configuration Standards
• Manageability - Operations through monitoring standards
• Planning - Program Manager - using ADM/Scrum standards
• Serviceability - Support using support standards

Wrap it up

You need to have some level of design to be successful for a system of any size, but too much architecture can slow down, or stop the implementation. Use consistent models and views that take into account the entire system; not just the UI and some functional stories.

In the end, the design will happen anyway. If it isn't formalized somehow (at least in some words and a diagram), then it's in the heads of whoever wrote the code. I have made some fairly large systems this way; but paid for it in the complexity of conveying that design to more people than myself. In the end the complexity of that mental model overwhelmed me. By using a simple template it becomes easy to account for what is going into the system, and much easier to share as a result.

Start with a lean definition of this for your needs; you don't have to re-invent the wheel here, just use the template.