Essay for an efficient work alignment, collaboration and interactions.
© Robert Zaremba https://scale-it.pl
Version 2.7 (2018.08)
“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:
Success is an effect of: organization, risk management, focus, open mindset and proactivity. Having the idea is just a small part of the process.
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 main principle is that the team matters. You should respect the team and the work the team is doing.
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.
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.
Encourage is the principal for building an efficient and sustainable environment.
Increase your productivity through better scheduling. Tips below comes from the asana team.
Agile software development is an umbrella term for several software development methods (including Extreme Programming and Scrum). More on this below.
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.
As practice, workflow is about creating structure through methodology, process and patterns. Agile is about adapting to change and evolution as you go.
Agile methods were influenced by the ideas of lean manufacturing. The main lean principles are:
Build faster → Measure faster → Learn Faster
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?
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:
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.
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
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.
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:
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.
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.
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,
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
Without a clear plan, you might find yourself running a race without a route.
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!.
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.”
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.
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.
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:
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.
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.
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).
Leading by example, Atlassian agile teams form three product divisions: make, sell, and operate.
Each division constitutes 3 phases managed by separate teams:
Understand the market, targeted customer personas, and good product design principles
Define the value proposition, product goals, and minimum viable product
Develop the product using sound, sustainable engineering practices
Understand the product's competitive landscape and market evolutions
Create messaging that highlights the product's value propositions to each customer segment
Build collateral to support the product launch: web pages, announcement emails, blogs, videos, etc.
Release software to customers with a regular cadence
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.
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.
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.
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:
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.
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.
Don’t overdesign! Working software over comprehensive documentation!
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 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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
Communicate this across all organizations (from devs to presidents).
SRE is a perspective way of accomplishing DevOps philosophy. SRE implements DevOps.
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
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 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:
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:
SLO are both upper and lower bounds. This is for two reasons:
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...
Google Cloud Platform Blog provides nice explanation at the SLOs, SLIs, SLAs, oh my - CRE life lessons.
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.
Agile ⇒ Lean: Build faster - Measure faster - Learn Faster
© Robert Zaremba https://scale-it.pl