/

AGILE WORKFLOW

Essay for an efficient work alignment, collaboration and interactions.

© Robert Zaremba https://scale-it.pl

2016

Version 2.7 (2018.08)


Table of Contents

Table of Contents

1. Introduction

Successful execution

2. Work Principles

The Team Matters

Be Open

Be Proactive

Be Encouraging

Be Productive

Be Agile

3. Agile

Structure vs change

Agile is Lean

The Lean startup.

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. Extreme Programming

XP Ceremonies

XP Release planning

Sprints / iterations

Testing Rules

System Metaphor

Define success metrics

Data-driven planning

KPI for the Roadmap.

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

8. 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 for:

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.

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.

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.

Structure vs change

As practice, 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 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 to watch: How Today's Entrepreneurs Use Continuous Innovation).

How to validate your next idea?

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 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 a 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 has 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 Pageduty.

Postmortem reports

After each problem, create a postmortem report. Share it with your teams and make sure everybody learn 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 ahead of development.

Planning / Scoping

The goal of scoping is to define all stakeholder objectives. Plan ahead for planning!. The project leader have to describe what he wants and why. He have 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 on the teams 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 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 an 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. Therefor 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. 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 eXtream 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 engage 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.
  4. Keep on track with the sprint plan.
    Work principles:  
    Keep on the sprint plan. Measure. Communicate!
  5. Weekly sprint review.
    Everybody will present their work (shortly, max 3min per person).
  6. 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.

7. 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 got out of spec.

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

Canary things. Roll things out to small percentage of the meet 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 us: 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 ramification 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.

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

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

source: http://dilbert.com/

© Robert Zaremba https://scale-it.pl