/

AGILE WORKFLOW

Essay for an efficient work alignment, collaboration and interactions.

Version 2.10.0 (2020.01)

 ©2016 Robert Zaremba https://zaremba.ch


Table of Contents

Table of Contents

1. Introduction

Successful execution

2. Work Principles

The Team Matters

Be Open

Be Proactive

Be honest

Be Encouraging

Be Productive

Be Agile

3. Agile

Structure vs change

Agile is Lean

The Lean startup.

MVP

Be Agile ⇒ Be Lean

Be Agile ⇒ Empower the Team

4. Use the project management tool efficiently

Asana

Keep Asana as it’s your Database of work

Keep your asana organised!

Keep the base with your customers.

CRM

Learn From Analytics

5. Planning

Prioritize Maniacally

Be aware about new, distracted ideas

Sprint plan vs roadmap

Meetings

Severity issues

Communicate, communicate, communicate

Postmortem reports

Product phases

Planning / Scoping

Design

Design thinking.

You are not your user.

Put yourself into the customers’ shoes.

Caution

Collaboration

Development

Working software over comprehensive documentation

Anticipate problems

Documentation

6. Shape Up

Shape the work

Betting table

Hill charts

7. Extreme Programming

XP Ceremonies

XP Release planning

Sprints / iterations

Testing Rules

System Metaphor

Define success metrics

Data-driven planning

KPI for the Roadmap.

8. Growing: multiple teams

Cross-functional team and product definition

Dependencies

Manage Constraints Rather than Dependencies

Forming a team

Site Reliability Engineering

Service Level Objective (SLO) and Service Level Indicators (SLI)

Service Level Agreement (SLA)

Risks and error budgets

9. Still not convinced if your Boss will buy it?


1. Introduction

“Genius is 1% inspiration and 99% perspiration” 

-- Thomas Edison

Workflow optimization is all-time emerging field in the business. Even so, all companies have problems with efficient workflow. The document presents ongoing investigation into the central goal: “Efficient IT work”. I created this document based on my corporate and startup experience. I’m an IT Leader and Software Expert. However this document is not about software. It’s about work methodology.

In a corporate world I was exposed to the big organization schemas. In startups, among many things, I was responsible for product delivery, system architecture and team building.

Creating an efficient IT structure is very challenging and super important for the business health, work quality and performance. It’s exceptionally difficult in the startup world when you need to be responsive to:

Successful execution

Success is an effect of: organization, risk management, focus, open mindset and proactivity. Having the idea is just a small part of the process.

2. Work Principles

This is a learning in the business life that first of all you need to have commitment, dedication and passion for what you are doing.

-- Lakshmi Mittal        

The key to effective management of agile teams lies in the mastery of soft skills.

The Team Matters

The main principle is that the team matters. You should respect the team and the work the team is doing.

Be Open

It is important we all know what’s going on behind each other’s screen to some extent. Be open, share with your teammates your achievements and successes as well as your problems and issues. Don’t hesitate to tell when things frustrate you, when something really motivates you.

We are working in a team, hence we have to behave as a team. Always inform your colleagues about your issues, what’s your day plan, when they can count on you. Always inform about non-default schedule.

It’s normal that you have private things to do. But don’t hide it. Others may expect something from you. Let them know that you won’t be available (if it’s something longer).

Use Asana to track you work and share the updates and goals with others.

Be Proactive

Always share ideas you think are good! Focus on what you can do, rather than what you can’t. Be proactive ⇒ be positively active & be reasonable = able to make reasoning.

Plan — if you have impediments, issues or something which puts the delivery into a risk - plan it. Proactive people plan ahead. Think about the impact. Discuss it. Best if you can propose some preliminary solutions.

Be honest

This is very important. We can’t plan or communicate well if you are not honest. If you have a problem -- let us know. Otherwise we will fail to make a plan and work as a team. Remember the team performance depends on you.

If you have a personal issue — talk about it with someone you like in the team. It’s better to solve things together.

Be Encouraging

Encourage is the principal for building an efficient and sustainable environment.

Be Productive

Increase your productivity through better scheduling. Tips below comes from the asana team.

Be Agile

Agile software development is an umbrella term for several software development methods (including Extreme Programming and Scrum). More on this below.

3. Agile

In a nutshell Agile is a time-focused, iterative philosophy that allows to build a product step-by-step (incrementally), delivering it by smaller pieces. One of its main benefits is the ability to adapt and change at any step (depending on feedback, market conditions, corporate obstacles, etc.) and to supply only relevant products to the market.

To its advocates, Agile is a genuinely better way to run a company and an economy—better for those doing the work, better for those for whom the work is done, better for the organization itself. Instead of management extracting value from the firm, Agile generates value for customers and for society as a whole.

To understand Agile we need to look at the value company value through customer satisfaction and project risk. The picture below shows how does it work (compared to the traditional, waterfall approach), and the following sections will explain the mechanics of it.

Structure vs change

Workflow is about creating structure through methodology, process and patterns. Agile is about adapting to change and evolution as you go.

Agile is Lean

Agile methods were influenced by the ideas of lean manufacturing. The main lean principles are:

Build faster → Measure faster → Learn Faster

The Lean startup.

Identifying the most critical parts of you project and going step by step with strong validation between steps is the foundation of Lean methodology. Introduced by Eric Ries, Lean projects focus on interaction with customers and validation (worth watching: How Today's Entrepreneurs Use Continuous Innovation).

How to validate your next idea?

MVP

MVP does not only express the feature set, but also the approach (we should accept that product is not working perfectly, and we should drive the project to reach good enough quality).

Be Agile ⇒ Be Lean

Take Agile as the extension of the Lean.

A typical lean company follows a learn – measure – build cycle, and conducts many tests, frequently connects with customers, understands their value and focuses its key processes to continuously improve it. A never ending cycle leads the teams to sustainability, smart development and success.

Let’s put them together:

Agile Philosophy

Lean Philosophy

Execute tasks faster, adapt to changes easier

Smart development, when you improve virtually everything you do by eliminating anything that doesn’t bring value to the customer

Makes the developing process flexible

Makes the developing process sustainable

Was initially designed for Software Development, then expanded to Marketing, and is currently applied in other areas

Started from traditional manufacturing and expanded to all existing industries

Action loop: product backlog – sprint backlog – iteration (sprints) – potentially shippable result

Action loop: build-measure-learn

Method for demonstrating progress — definition of ‘done’

Method for demonstrating progress — validated learning

Methodologies: Scrum, XP, FDD, DSDM, Crystal Methods etc.

Methodologies: Kanban, Kaizen etc.

Toolkit: sprints, boards, Scrum Master, acceptance tests, user story mapping etc.

Toolkit: hypotheses, split (A/B) tests, customer interviews, funnel and cohort analysis, Customer Success Manager etc.

Be Agile ⇒ Empower the Team

The best architectures, requirements, and designs emerge from self-organizing teams.

-- Agile Manifesto

One of the key important aspects of a successful Agile setup is having a self-organizing team.

Self-organizing team take responsibility and manage their own tasks and don’t rely on a manger to tell them what to do. Team members:

Development Teams are structured and empowered by the organization to organize and manage their own work.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done

-- Agile Manifesto

4. Use the project management tool efficiently

Asana

My project management tool of choice is Asana.

Projects are lists of tasks. Use a project for a larger goal and a task for an action someone on your team needs to take in order to achieve that goal.

-- asana.com

You can use projects to express different goals of your work schedule:

Slice and dice your tasks into multiple projects - this way you will deliver better overview of the work and features. This idea is nicely presented in Project management, goal setting, roadmaps, pipelines… video.

Asana projects go beyond simple task list view:

  1. Check overview of Project Views tutorial to get ideas about sections, ordering, default views, explore files directory, calendar….
  2. Slice and dice your tasks as mentioned above. Get inspiration from the following presentations:
  1. Tribeca Film Festival plans and runs events #withAsana
  2. Pantheon sets company objectives #withAsana
  3. Autodesk manages editorial calendars #withAsana
  4. General overview of project management

Keep Asana as it’s your Database of work

It’s uber useful for the team and the company if we can aggregate information (links, decisions, files) in a feature tasks. This way we will not get lost. Connecting work video tutorial explains it perfectly.

Keep your asana organised!

Keep the base with your customers.

As a side note, next to the tooling I want to highlight the importance of tracking the customer behaviour and contracts. This means both: the marketing, support and analytics.

Make sure you use the right tools across your company.

CRM

Manage your customers, contacts, and sales with the help of a simple CRM. Customer relationship management is a business strategy that stresses good ongoing relationships with customers. It holds that maintaining these relationships drives growth and profitability. CRM software can help by synchronizing customer communications among business units. Sales, marketing and customer service can all get on the same page. It’s a system of record for touch points throughout the customer lifecycle. Features: customer data management, sales force automation, marketing automation, customer service & support,

Learn From Analytics

You can learn about what makes your customers tick by studying the data produced by your reporting systems. Information from profiles, preference centers, and activity can all be combined to give you a better idea of what they truly want and need from the relationship. Having a strong data foundation is having power because it puts you in position to make smarter business decisions and better anticipate the needs of the customers. This is when your finely targeted and tailored messages are likely to have the most impact.

Analytics is no secret, but still it is one of the more underutilized of business tools. Some organizations don’t use anything at all while others fall into the trap of limiting themselves to a single solution.

Examples: Amplitude, Countly, Mixpanel, Google Analytics, Heap

5. Planning

Without a clear plan, you might find yourself running a race without a route.

-- wavelength_blog

Remember - to successfully complete objectives you need to carefully plan and explain them. Don’t make the plan by your own! Plan and estimate correctly!.

Prioritize Maniacally

What you prioritize is what you value as a company. So, the prioritization process is the process through which you determine and express the company’s values. Ensure that you don’t do anything that isn’t the next most important thing that can be done. The clearest sign that smart prioritization isn’t happening is stupid perfectionism; if you see that happening, you know you need an upgrade to “more maniacal.”

Be aware about new, distracted ideas

It’s hard to make meaningful progress when you’re constantly open to changing strategy. On the other hand, rejecting all new ideas is the opposite of fostering the kind of organization that can learn, adapt, and react quickly.

Sprint plan vs roadmap

Roadmap is a high level set of big user-stories. It’s there to define the big objectives and priorities. Roadmap helps the sprint planning process to deliver important features to the user and keep the system in good condition.

Sprint, on the other hand, is to deliver incremental updates leaned into roadmap.

Meetings

Principles around meetings:

Note: each meeting should have a goal and agenda. If the meeting doesn’t bring any value then it means that the workflow requires some reorganization or there is something wrong with management. Make sure that:

Severity issues

Each project has to plan for handling different severity issues. It’s good to define them upfront:

The IT teams have to plan together how to communicate and share the experience.

Communicate, communicate, communicate

In case of outage and critical error we have to have a channel where everybody can jump in easily and help. Slack #showstopper is the minimum. You need to have notification channel with mobile support which will notify right persons, something like Pagerduty.

Postmortem reports

After each problem, create a postmortem report. Share it with your team and make sure everybody learns from it. Try to mitigate similar problems by implementing solutions (tools / processes).

Product phases

Leading by example, Atlassian agile teams form three product divisions: make, sell, and operate.

Each division constitutes 3 phases managed by separate teams:

Division

Phase

Focus

Make

Product Management

Understand the market, targeted customer personas, and good product design principles

 

Design

Define the value proposition, product goals, and minimum viable product

 

Development

Develop the product using sound, sustainable engineering practices

Sell

Product Management

Understand the product's competitive landscape and market evolutions

 

Design

Create messaging that highlights the product's value propositions to each customer segment

 

Marketing

Build collateral to support the product launch: web pages, announcement emails, blogs, videos, etc.

Operate

Product Management

Release software to customers with a regular cadence

 

Development

Respond to customer issues

 

Support & Ops

Relay customer feedback to the “make division” (Dev, PM, Design) as input for future product development

The “Make” Division (development):

Scoping (planning) is done in one sprint ahead of design. Design is done one sprint ahead of development.

Planning / Scoping

The goal of scoping is to define all stakeholder objectives. Plan ahead for planning!. The project leader has to describe what he wants and why. He has to involve in this process business stakeholders to make sure that the objectives are in line with the product goals, and clear and extensive to think about the solutions.

Create grooming session during the sprint to carefully scope and design next features.

Design

During the design phase we want to define user and system requirements, describe the user stories. This process have to involve IT (architect and developer) to be sure that the design is aligned with the system architecture and define correct timeline for it.

Design thinking.

Following the lean approach there is a “Design thinking” strategy. It is just a way of approaching problems that focus on a human being. For instance, let’s all agree and validate what the problem even is first. Then it’s stuff like mapping, prototyping, and validating assumptions as a group — because all parts of a product team (business, design, and engineering) need to be involved. Start with a basic sketches approach (napkin style). Evaluate ideas and solutions when they are still on napkins. You can’t focus on the important things (like, is it solving the problem? Do we have a hierarchy of actions to be taken?) when you’re distracted by colors and button styles and typefaces. It is an absolute mistake to jump straight to high-fidelity visual design or “re-skin” a prototype that has already been made, or so help me, make a logo for a product with no defined experience. Christoph Meinel and Larry Leifer, of the HPI-Stanford Design Thinking Program, laid out four principles for the successful implementation of design thinking:

You are not your user.

Obviously you need to research and test quite a bit. Remote testing and recruitment tools have come a long way in the past four years, so there’s no excuse. The most effective strategy is participatory design, bringing users into our workshops. Not only can you watch them use things, they can give immediate feedback, and ideate with you.

Put yourself into the customers’ shoes.

This is very important for the product owner like role. We are creating a product for a customer, not for yourself. So always think about the customer.

Organizationally, we need to understand their business, markets, industry, key strategies/drivers, key challenges, how things get done within the company, and more.

Individually, we need to understand what makes them tick, what they worry about, what their personal goals/ambitions are, how they are measured, how they spend their days, and more.

The better we are at connecting with them–where they are, the more effective we will be in identifying how our products and solutions might help them achieve their goals.

We want to be able to mirror their experience, sharing ideas and engaging them in relevant conversations about them and their organizations.  The more we understand and can be empathetic, the more effective we will be in engaging them in meaningful ways.

Caution

Don’t overdesign! Working software over comprehensive documentation!

Collaboration

Collaborating well is critical in this space where it’s highly unlikely any one person in the team understands all areas perfectly. Often teams are remote (decentralized!) and so you have to come up with new strategies to create that “everyone in the same room” dynamic. Old school paper works well with camera!

Development

Development starts with the analysis - collecting the solution ideas and finding possible obstacles which haven’t been defined during the design phase. For non trivial tasks, developer will present his solution idea to the rest of the development team for review before coding the solution. If it’s required, a developer works closely with the business to implement the solution and refine the spec document.

Be clear who owns what part of the work. This way we encourage accountability and empower every contributor to play their part in achieving the broader goals.

Working software over comprehensive documentation

Here is a typical development process: from research to synthesis and implementation. The further up with this chain you go the worst Agile methodology works by itself. Remember: the main goal of agile is to provide working software in a proactive environment, not define long term strategy.

Anticipate problems

For more complex tasks, it’s good to do incremental solution idea review. The developer comes with his solution idea and the review is a brainstorm of new ideas and roadblocks. The obstacles you will find can often be gleaned from past failures. Other times, they’re determined by vividly imagining just how certain scenarios will play out

Documentation

The documentation, data and code language is English.

Documentation has many forms: code comments, tests, diagrams, spec documents… In the lean environment the principal artefact of the work is a product. Although much documentation can be replaced with highly readable code and tests, in a world of evolutionary architecture it's important to record certain design decisions for the benefit of future team members and for external oversight. Therefore it’s a good habit to organize the list of objectives, requirements and user stories from the scoping / planning sessions. Another form of the documentation is Lightweight Architecture Decision Records. At some point it’s enough to store information in the project management tool → Keep Asana as it’s your Database of work.

To model the feature design use:

Diagram and module specification have to be stored in DEV Wiki folder in Google Drive. Diagrams should be created using Google Drawing or draw.io

6. Shape Up

Shape Up is for product development teams who struggle to shape, build, and ship. Written by the innovators behind Basecamp.

“For one, we’re not into waterfall or agile or scrum. For two, we don’t line walls with Post-it notes. For three, we don’t do daily stand ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end. No backlogs, no Kanban, no velocity tracking, none of that. We have an entirely different approach. One developed in isolation over nearly 15 years of constant trial and error, taking note, iterating, honing in, and polishing up. We’ve shaped our own way.”

Jason Fried, Basecamp

Below I’m copying a brilliant summary of Shape Up by Sachin Rekhi.

Shape the work

Before even considering a project for building in an upcoming cycle, the Basecamp team always shapes the work. The idea is to make an abstract project idea more concrete by defining key elements of the solution before betting on it. A small group of senior members work on shaping projects in parallel to all the execution teams that are focused on delivering projects that have already been shaped and approved.

The key with shaping projects is it isn't equivalent to putting together a product spec for the project. It's instead at a higher level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. As part of shaping a project, you might put together a fat marker sketch, which is a low-fidelity UI sketch of the solution that conveys a high-level design without actually defining the details. You also define an appetite, which is how much time you want to spend on this project based on how much you believe this project is worth in terms of customer and business impact. This is opposed to simply coming up with an estimate of how long the project will take. Each of these elements ultimately gets put together in a short pitch, a document that presents the problem, the appetite, and the solution of the now-shaped project idea for consideration in the roadmap.

The reason this approach is compelling is it allows you to better understand the consequences of taking on a potential project during roadmap planning. Too often in roadmap planning we approve high-level projects like "Redesign the homepage", "Add a calendar view", etc without fully understanding them. We leave it to the teams to figure out the details and deliver a solution. The challenge is after approving the project, we might not like the ultimate outcomes. The finalized design might do far more damage to the overall product experience than good. Or the project might overrun it's initial estimate, derailing all our other plans. By shaping the work upfront and understanding what the potential solution might be before deciding to take on the project, we significantly reduce the uncertainties associated with accepting the project.

Betting table

In a roadmap planning meeting they bring together a few senior leaders at the company (CEO, CTO, head of strategy, and senior eng leader) to decide the projects for the upcoming 6-week cycle based on the pitches that were prepared to be reviewed. Everyone has already had a chance to deep-dive into each shaped project by pre-reading the pitches. This allows the discussion to be very focused on debating each pitch and deciding on it's inclusion relative to the priority of the other pitches. During a betting table meeting, they may debate for each pitch how important the problem is worth solving, debate whether the appetite is the right one for this problem, and even debate whether the proposed high-level design is an attractive solution.

This process ends up allowing the senior team to be far more involved in ensuring the right projects are green-lit based on a holistic view of the problem being solved, the resources required to solve it, and the elegance of the solution as opposed to taking a far riskier bet on a raw idea and simply hoping the team comes back with a properly scoped great solution. It's also far more cost effective than making these calls in late-stage product reviews where it's so expensive to make any meaningful changes to the product when it's already begun implementation.

The process also ends up being far lighter-weight than a traditional spec review process that often precedes implementation of a project. While this traditional process does allow the senior team to review critical elements of a proposed solution before implementation, the fact that it's heavier-weight means that it's traditionally only used for large endeavors and usually skipped for small feature implementations, which usually don't enjoy senior oversight and consideration, which can result in feature implementations that aren't cohesive across the entire experience nor appropriately scoped relative to the level of impact.

Hill charts

The Basecamp team has also reinvented ongoing project status by creating an alternative mechanism for sharing how far along each project is. Traditional project management status struggles with a few issues. Some teams simply look at the number of tickets for a given project and chart the completion of those tickets to provide status. Of course not every ticket is created equal so this gives you a poor sense of project progress. Even if you added estimates to each ticket, as projects progress, more tickets are created as new implementation details are discovered or new bottlenecks are understood. This results in an increase in the number of tickets, which means any initial estimate you were making based on the tickets is still wrong. While you can spend significant time upfront coming up with all implementation tasks and scoping a project, this is often wasted effort when its more realistic to discover detailed tasks as the project progresses.

Basecamp throws out these traditional approaches to ticket-based project estimation and status and replaces it with a hill chart, which is a diagram showing the status of work on a spectrum from unknown to known to done. Early in a project, when you are going uphill, you are still discovering all the edges of the work, creating lots of new tasks as you progress. Once you've understood the full solution, you move from the unknown part of the project to the known part of the project where you're simply executing against the tasks that are well-defined and understood. What Basecamp does it create a hill chart for each project and plot each project scope, or component, along the hill chart, giving you a high-level view on where the team believes it is on each of the project components. Leaders can see the current status, but more importantly, track movement across the hill charts. Project scopes that remain stuck are areas for leaders to drill in to see if they can help resolve the bottleneck.

This far simpler project status approach requires far less effort to keep up-to-date but still provides leaders with the transparency they need in order to understand where projects stand and be able to offer to help when needed.

7. Extreme Programming

Starting with some framework from the very beginning is uber important.

There are many good methodologies applying Agile principles. I’m in favour of the eXtreme Programming (XP), which works very well in the startup environment. Other methodology, which works especially well in the enterprise environment is Scrum.

XP focuses heavily on ensuring the quality of delivered software which prescribes engineering solutions towards that end. It solicits feedback immediately - you don’t have to wait for the new sprint to tackle the feedback.

XP Ceremonies

The team engages in Release Planning and Iteration Planning. They work in very short development cycles so that changes requested by the customer (who works on-site with the team) can be incorporated frequently.

  1. Quarterly roadmap review.
    Time to dream big and review all ideas we wrote down over the past months.
    Make few events: one for your team and one for the business and development together.
  2. Weekly sprint planning.
    Goal: define the sprint tasks you will commit on.
  3. Daily stand-up.
    Goal: quickly find what’s blocking. Help and support.
    In a distributed environment can be done in a short report form in your chat app. Each morning, when you start a work you communicate in 3 paragraphs:
  1. DONE: what have you done.
  2. DOING: what are you planning to do.
  3. BLOCKING: what is blocking you, what’s not clear. Describe your problems.

Even if something was discussed, it’s better to repeat yourself in daily update than not doing it at all.

  1. Keep on track with the sprint plan.
    Work principles:  
    Keep on the sprint plan. Measure. Communicate!
  2. Weekly sprint review.
    Everybody will present their work (shortly, max 3min per person).
  3. Retrospective every 2 weeks.
    Discuss process improvements, successes and failures.
    The team is obligated to note their comments during the sprints. Organize them in 4 categories:
  1. Start doing
  2. Stop doing
  3. Do more of
  4. Do less of

Make a document retrospective_sprint_id, where we will share all our comments at the beginning of the retrospective. Start each retrospective by reading the previous retrospective document.

extreme-programming-project.gif

XP Release planning

Start out collecting user stories.

After user stories have been written you can use a release planning meeting to create a release plan. The release plan specifies which user stories are going to be implemented for each system release and dates for those releases / milestones. It is important for technical people to make the technical decisions and business people to make the business decisions.

The release plan is then used to create iteration plans for each individual iteration.

The base philosophy of release planning is that a project may be quantified by four variables; scope, resources, time, and quality. You can quantify maximum 3 out of 4 variables. 

Sprints / iterations

Each iteration is 1 to 2 weeks long. Begin your iterative development with an iteration planning meeting. Selected user-stories are translated into individual programming tasks to be implemented during the iteration to complete the stories.

Don't schedule your programming tasks in advance. Instead have an iteration planning meeting at the beginning of each iteration to plan out what will be done.

It is also against the rules to look ahead and try to implement anything that it is not scheduled for this iteration.

Testing Rules

  1. All code must have unit tests.
  2. All code must pass all unit tests before it  can
  3. be released.
  4. When a bug is found tests are created.
  5. Acceptance tests are run often and the score is published.

System Metaphor

It is a metaphor for a simple design with certain qualities. The most important quality is being able to explain the system design to new people without resorting to dumping huge documents on them. A design should have a structure that helps new people begin contributing quickly. The second quality is a design that makes naming classes and methods consistent.

What you name your objects is very important for understanding the overall design of the system and code reuse as well.

Define success metrics

Recall the Lean Principle:

Build faster → Measure faster → Learn Faster

Data can be an incredibly powerful communication tool, but even the most informed product teams can skew or misunderstand the purpose of a new feature because of a miscommunication.

Data-driven planning

As a Project Leader, during Scoping and Design stay clear about the most important goals that can be solved during the sprint. Drive the user stories using the data (metrics). Establish baselines by gathering metrics and tracking how new features and processes impact them.

However, sometimes the data won’t be able to tell you how to prioritize and scope or why the metrics are shifting (doing opposite than expected). Rely on your best judgment, test often, and build in frequent reviews to see what tactics are causing metrics to shift in the direction you want.

KPI for the Roadmap.

It’s crucial to define KPIs for your roadmap. What brings the value to the customers? Does the system works seamlessly? Measure completeness of your roadmap and KPIs for each sprint planning.

Security

Development teams are under pressure. Quality releases needed to be delivered on time. Coding and compliance standards need to be met. And mistakes are not an option.

Make sure you integrate sufficient measures (practices, methodology, tools and processes) to ensure system security.

Treat Model

Threat modeling is a type of risk analysis used to identify security defects in the design phase of an information system. Threat modeling is most often applied to software applications, but it can be used for operating systems and devices with equal effectiveness. Threat modeling is typically attack-centric; threat modeling most often is used to identify vulnerabilities that can be exploited by an attacker in software applications.

STRIDE technique (list of basic threats):

Read: 12 methods for threat modeling

Static Code Analysis

Static code analysis is a method of debugging by examining source code before a program is run. The sophistication of the analysis performed by tools varies from those that only consider the behaviour of individual statements and declarations, to those that include the complete source code of a program in their analysis. The uses of the information obtained from the analysis vary from highlighting possible coding errors (e.g., the lint tool) to formal methods that mathematically prove properties about a given program (e.g., its behaviour matches that of its specification).

Limitations:

Example tools:

Below we will list a common techniques..

Data Flow Analysis

Data flow analysis is used to collect run-time (dynamic) information about data in software while it is in a static state (Wögerer, 2005).

Control Flow Graph (CFG)

An abstract graph representation of software by use of nodes that represent basic blocks. A node in a graph represents a block; directed edges are used to represent jumps (paths) from one block to another. If a node only has an exit edge, this is known as an ‘entry’ block, if a node only has a entry edge, this is know as an ‘exit’ block.

Taint Analysis

Taint Analysis attempts to identify variables that have been ‘tainted’ with user controllable input and traces them to possible vulnerable functions also known as a ‘sink’. If the tainted variable gets passed to a sink without first being sanitized it is flagged as a vulnerability.

Lexical Analysis

Lexical Analysis converts source code syntax into ‘tokens’ of information in an attempt to abstract the source code and make it easier to manipulate (Sotirov, 2005).

8. Growing: multiple teams

Over the time, once the development team grows above 8 people we should form multiple teams.

An agile team must possess all the required skills (cross functional agile teams), but sometimes it's necessary to call on specialists for specific work.

By definition:

An Agile team is a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product.  

Dedicate these people to the team, and as a rule, do not move them between or across teams as demands ebb and flow.

Cross-functional team and product definition

Being cross-functional doesn’t mean that the team has to be able to do everything (design, frontend, backend, analytics …). We need to finely define the product the team is building. A product is actually a sub-system of a larger systems-integration.

Cross-functional means that team has to be able to build the product.

Dependencies

Dependencies are unavoidable. They are always there. Don’t try to fight them. No amount of daily standup meetings is going to fix this problem. Instead learn how to:

Keep the following as a rule of thumb:

The more you manage dependencies the less Agile you will be.

Manage Constraints Rather than Dependencies

The solution lies in the application of Kanban to model the flow of value across teams, to make smaller investment decisions at the portfolio level, to limit the amount of work in process, and to redeploy people and teams in ways where everyone all the time, is focusing on the highest value initiatives within the organization. We use agile at the team level to inspect and adapt and to make sure we are always focusing on delivering the most value possible in any given sprint. Using Lean and Kanban and Theory of Constraints gives us that same ability when we are dealing with dependencies at any level of the organization.

Forming a team

Agile teams go through four key phases as they develop:

Keeping agile teams intact takes some organizational discipline, but it pays to protect the team–within reason, of course. When change is introduced (new hire, employee departure, etc.), the team reverts back to the forming stage as it absorbs the change.

Site Reliability Engineering

Communicate this across all organizations (from devs to presidents).

SRE is a perspective way of accomplishing DevOps philosophy. SRE implements DevOps.

DevOps

SRE

Reduce Organizational Silos. By breaking down barriers across teams, we can increase collaboration and throughput.

Share ownership of production with developers. Use same tooling in order to make sure everyone has the same view and the same approach.

Accept failure as normal

Blameless postmortems.
Use a concept of error budget of how much the system is allowed to go out of spec.

Implement gradual change. They are easier to review, it reduces the time to recover making it simple to roll back.

Canary things. Roll things out to a small percentage of the users before moving out to all users.

Leverage tooling and automation.

Eliminate manual work as much as possible. Measure how much toil you have. Automate this year’s job away.

Measure everything.

Measure that amount of toil you have, reliability and health of your systems.

SREs focuses on solving classic problem: developers want to push and release new features. Operators aim for stability and maintenance. Speed vs reliability.

For SRE we have 2 categories of responsibilities:

Service Level Objective (SLO) and Service Level Indicators (SLI)

How to come up with a precise numerical target for system availability? We term this target the SLO of our system. It’s an agreement among stakeholders about how reliable a service should be. Cost and technical complexity of making service more reliable gets higher and higher the closer to 100% you try to get. Make sure you have enough room for error and enough room to roll out features reliably. To do this, you need to define:

  1. What availability is. Have clear numeric indicator. You do this by defining Service Level Indicators. This are metrics over time such as: request latency, throughput, failures per request over time.
  2. What proper level of availability is in context of SLI. Add all the SLI up or integrate it over a longer period of time (eg: a year) to see if the total amount of errors/downtime that we’ve had more or less the the specified SLI.
  3. Plan in case of failure. Put everybody on the same page.

SLO are both upper and lower bounds. This is for two reasons:

  1. If you try to run your service much more reliable than it needs to be, you are slowing down the release of features that you want to get out and make your customers happier.
  2. It’s an expectation that you are sending for your users, that if you suddenly start breaking a lot more often they are used to because you start running exactly at your SLO rather than doing much better than your SLO, than users will be unhappily surprised if they’re trying to build other services on top of yours.

Service Level Agreement (SLA)

It says: here is what I’m going to do if I don’t meet the level of reliability that is expected ~ business agreement associated with SLO.

SLIs drive SLOs which inform SLAs

SLAs describe set of services and availability promises that a provider is willing to make to a customer, and then the ramifications associated with failing to deliver on those promises. Those ramifications might be things like money back, free credit...

Example:

Google Cloud Platform Blog provides nice explanation at the SLOs, SLIs, SLAs, oh my - CRE life lessons.

Risks and error budgets

Accept failure as normal by quantify failures and risks through error budget. It enforces gradual change, because non-gradual change could quickly burn all error budget breaking the SLO.

SLO defines error budget. If we approach SLO we need to reduce the risk and not accept risky features in order to balance innovation and stability to an appropriate level.

9. Still not convinced if your Boss will buy it?

Agile ⇒ Lean: Build faster, Measure faster, Learn Faster

source: http://dilbert.com/

© Robert Zaremba https://zaremba.ch