Skip to content

Agile and DevOps

Jump to bottom
Tomas Tulka edited this page Feb 9, 2022 · 63 revisions

Efficiency vs Effectiveness

Efficiency is doing things right. Effectiveness is doing right things. ~ Peter Drucker

Efficiency is necessary but no longer sufficient to be a successful organization. [a]

Management models based on planning and predicting instead of resilient adaptation to changing circumstances are no longer suited to today's challenges. Organizations must be networked, not siloed, in order to succeed. Their goal must shift from efficiency to sustained organizational adaptability. [a]

  • Digital giants like Google or Amazon aren't technology companies; they are advertising or fulfillment companies that understand how to use technology for competitive advantage.

The more you optimize elements of a complex system of humans and nature for some specific goal, the more diminish that system's resilience. A drive for efficient optimal state outcome has the effect of making the total system more vulnerable to shocks and disturbances. [a]

You can only optimize for efficiency if you can identify x and y sufficiently far in advance to build a dependable system for converting one into the other; the pursuit of efficiency is grounded in prediction. [a]

Robustness is achieved by strengthening parts of the system (e.g. an Egyptian pyramid); resilience is the result of linking elements that allow them to reconfigure or adapt in response to change or damage (e.g. a coral reef). [a]

To survive, we need to become both robust and resilient. [a]

Automation is not just about efficiency but primary about repeatability and resilience.

  • Wherever humans are involved, mistakes are bound to happen, and work will be performed ad hoc without proper documentation.
  • The error rate is likely to be the highest for infrequently performed tasks because the operators are lacking routine.

Diverse specialized abilities are essential. We wanted to fuse generalized awareness with specialized expertise. [a]

The speed and interdependencies of the modern environment create complexity. Coupling shared consciousness and empowered execution creates an adaptable organization able to react to complex problems. [a]

Digital Transformation

Digital transformation isn't a matter of convenience, but of corporate survival. [b]

To be genuinely digital, an organization must change the existing business model. [b]

  • Digital companies are not out to replicate existing business models. Rather, they choose weak sports that are highly inefficient or cause unhappy customers.
  • Instead of being a good guesser, companies need to be fast learners so that they can figure out quickly what works and what doesn't.
  • External consultants and vendors can give a boost, but they cannot substitute for an organization's ability to learn.
  • Copying digital leaders won't make you digital. This fallacy is known as the cargo cult. You can't copy-paste culture!
  • The cultural change must come from within. Cultural changes must be instilled by the company leadership.
  • Many successful traditional businesses suffer from the problem of having too much money.

Innovator's Dilemma - Most innovative products can't match established products' performance or profitability during early stages. Traditional budgeting processes may therefore reject new and promising ideas.

^                    ^
|                    |     /
|     /----          |   /
|----/               | /
+----------> t       +----------> t 

Project thinking vs. Constant change

If you want to speed up a project, look to reduce friction instead of adding more resources. [b]

  • Adding more resources is likely to increase complexity, exacerbating the problem.

We know that just adding more people to a team does not make that team go faster. In a lovely study of more than 4,000 software projects that compared the relative performance in teams of 5 or fewer and teams of 20 or more, the teams of 5 took only one week longer than the teams of 20 people over a 9-month period. So small teams are nearly 4 times as productive. [g]

Outsourcing IT has severe drawbacks in the digital age because it excludes the organization from the critical innovation cycle.

Digital transformation is driven by democratization; giving everyone rapid access to resources. [b]

Lack of legacy is a key factor of difference between digital companies and traditional ones. [b]

  • Systems fall into the state of legacy because technology moves faster than the business.

For organizational systems, the systemic behavior is primarily guided by its culture. A significant portion of this culture derives from shared beliefs held by the organization's members. [b]

Folks coming from a digital company know the target picture but they don't know the path, especially from your starting point. [b]

DevOps

Conway's Law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of there organizations.

Another implication of Conway’s Law is that if we have managers deciding on teams, and deciding which services will be built, by which teams, we implicitly have managers deciding on the system architecture. – Ruth Malan

Agility is the ability to respond to changing product demands.

Holub's test for Agility: Once you discover the need for a change, even a significant one, can you get it into your user’s hands in a couple days or less?

DevOps: a working culture where all product owner, development, QA, IT operations and infosec work together. DevOps model encourages the whole team to make decisions and overtake responsibility as whole (no levels as architects, seniors, juniors etc.).

How people act and react is decisive, not the form of the organization. (Mike Rother in Toyota Kata)

Lead time: starts when the request is made and ends when it is fulfilled. Process time: starts only when we begin to work on the request.

  • In the absence of improvements, processes don't stay the same - due to chaos and entropy, processes actually degrade over time.

  • Strategic goals should speak to where the company is going, and how it sees itself as best making its customers happy. May not include technology at all.

A group called the DevOps team sitting between development and operations with the goal of moving faster and automating releases into production is an antipattern.

Most orgs have a usually small number of people “heroes” (from The Phoenix Project) who are called on to “save the day” when things go wrong or who are called on for the tricky changes that need to be made. If you have a hero in your organization, she needs to be working to spread her knowledge and to work with others to make the system more understandable. This is profoundly more valuable than the more usual firefighting that “heroes” more commonly undertake. [g]

Heroic efforts are a sign of dysfunction. If you need them, something's seriously wrong.

A new layout with an old culture can deliver the worst of both worlds: countless managers, eager to adopt the new trend that promises innovation but reluctant to abandon the org chart, have done away with cubicles only to produce a noisier, more distracting environment that is neither efficient nor effective. [a]

Cultures are more resistant to designed change than bricks and mortar. [a]

Lean Software Development

  1. Eliminate waste (everything what doesn't add a value to the customer is waste).
  2. Learning in small iterations.
  3. Decide as late as possible.
  4. Deliver as fast as possible.
  5. Empower the team (don't see people as resources).
  6. Build integrity in (refactoring).
  7. See the whole (think big, act small, fail fast, learn rapidly).

Social Aspects

  • Humility
    • Be open to self-improvement.
  • Respect
    • Care genuinely about others you work with.
  • Trust
    • Believe other to be competent to do the right thing.

While building trust gives teams the ability to reconfigure and "do the right thing," it is also necessary to make sure that team members must all work toward the same goal, and in volatile, complex environments that goal is changeable. [a]

A good argument is based on facts and reasoning; trust and authority; and emotions!

Learning Culture

Your ability to learn new things is your most important strategic asset. [f]

By removing blame, you remove fear; by removing fear, you enable honesty; and honesty enables prevention. (Bethany Marci)

  • When engineers make mistakes and feel safe when giving details about it, they are not only willing to be held accountable, they are also enthusiastic in helping the rest of the company avoid the same error in the future.
  • DevOps must allow this sort of innovation and the resulting risks of people making mistakes.

Education vs. training: Education is resilient, traning is robust. Education requires fundamental understanding, which can be used to grasp and respond to a nearly infinite variety of threads; training involves singular actions, which are useful only against anticipated challenges. Medical school is education, first aid is traning. [a]

  • The most organizations rely on change approvals, the worse their IT performance in terms of both stability an throughput. Ask a programmer to review ten lines of code, he'll find ten issues. Ask him to do five hundred lines, and he'll say it looks good. (Giray Özil)
  1. What was your last step and what happened?
  2. What did you learn?
  3. What is your condition now?
  4. What is your next target condition?
  5. What obstacle are you working on now?
  6. What your next step?
  7. What is your expected outcome?
  8. When can we check?

The overarching purpose of any form of prototype is to learn something at a much lower cost in terms of time and effort than building out a product.

Reserve 20 % for non-functional requirements and reducing technical debt

When organizations do not pay their "20% tax", technical debt will increase to the point where an organization inevitably spends all of its cycles paying down the technical debt. (Marty Cagan)

Paired programmers are 15% slower then two independent individual programmers, while "error-free" code increased from 70% to 85%. Since testing an debugging are often many times more costly than initial programming, this is an impressive result. (Laurie Williams)

Game Day

Helps teams to simulate and rehearse accidents to give them the ability to practice. First, schedule a catastrophic event, such as the simulated destruction of an entire data center. Then give teams time to prepare, to eliminate all the single points of failure and to create the necessary monitoring procedures, failover procedures etc.

Code Review Best Practices

After checking a piece of code into the codebase, it is no longer yours in any case.

  • Be polite and professional
    • It's better to ask questions on why something was done the way it was before assuming that approach is wrong.
  • Write small changes
    • Generally about 200 lines of code.
  • Write good change descriptions
    • What is being changed and why.
  • Keep reviewers to a minimum
    • Mostly precisely one reviewer.
  • Automate where possible
    • Use automatic static analysis of a given code change.

#noprojects

Projects are decoupling delivery from value, because it's much simpler to measure an output than an outcome.

  • Projects provide an illusion of predictability.
  • The requirements will not be completely known until after the users have used the finished product.

Project-management process is fundamentally designed to separate the work done from the business benefits. How many projects have you experienced that have claimed success (on time and on budget) but, after the project was closed and the project manager moved on, still failed to deliver the expected business benefits?

You are not in business to make money. That is not your purpose. If you’re focusing on making money, you’re not focusing on creating value for your customer. Making money is how you show that you are actually solving that need.

Output vs Outcome

A strong product culture means that the team understands the importance of continuous and rapid testing and learning. They understand that they need to make mistakes in order to learn, but they need to make them quickly and mitigate the risks. They understand the need for continuous innovation. They know that great products are the result of true collaboration. They respect and value their designers and engineers. They understand the power of a motivated product team.

More work gets done at those rare businesses where people care about the product, their superiors, and the company itself.

The Agile Manifesto

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.
  1. We value individuals and interactions over processes and tools. That is, while processes and tools can help sustain a consistent level of output, motivated individuals and teams collaborating and working together are more creative and can produce higher quality work.
  2. We value working software over comprehensive documentation. This means that while processes that support delivery are important, the team’s focus should be on delivering to the customer’s needs.
  3. We value customer collaboration over contract negotiation. Written contracts are still important. However, you should be treating your customer as a partner, not as an opponent. The goal of an agile contract is to facilitate rather than protect, though it can do that as well.
  4. We value responding to change over following a plan. Under agile, plans are useful as a guide, but adapting to your customer’s changing requirements brings greater business value to both you and your customer.

The main reason for the Agile movement is to bring business and development together.

Agile is to solve how to effectively organize a relatively small group of programmers to be effective.

Even the first column points are more important than the second column points, it doesn't mean we should eliminate the latter whatsoever. For example, we still need processes and tools (2), but individuals and interactions (1) are more important.

  • Successful outcomes over efficient delivery

If the software is your product, not the service of building it, then your highest priority had better be outcomes like more people trying, using, and continuing to use your product. Because those are the things that earn or save your company money. [d]

Agile vs. Waterfall

  • Typical roadmaps are the root cause of most waste and failed efforts in product organizations.
  • Truth is that at least half of our product ideas are just not going to work.
  • We need to solve the underlying problem, not just deliver a feature.
    • Fall in love with the problem, not with the solution.
    • Obsess over customers, not over competitors.
    • Customers don't know what's possible, and with technology products, none of us know what we really want until we actually see it.
      • Technology drivers (and enables) the functionality as much as the other way around.
      • If the first time your developers see an idea is at sprint planning, you have failed. We need to ensure the feasibility before we decide to build, not after.

Main components providing the business context:

  • Product vision and strategy - big picture of what the organization as whole is trying to accomplish and what the plan is for achieving that vision.
  • Business objectives - specific, prioritized for each product team.

Tell the team what you need them to accomplish and how the result will be measured, and let the team figure out the best way to solve the problem.

  • The product manager has the responsibility to understand the considerations and constraints of the various stakeholders, and to bring this knowledge into the product team.

The difference between vision and strategy is analogous to the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there.

  • The product vision should be inspiring, and the product strategy should be focused.

The role of the leader becomes creating the broader environment instead of command-and-control micromanaging. [a]

Don't try to please everyone in a single release. Focus on one new target market, or one new target persona, for each release.

Modern agile methods

  • Make People Awesome
  • Make Safety a Prerequisite
  • Experiment & Learn Rapidly
  • Deliver Value Continuously
  1. Make People Awesome - This includes the people who use, make, buy, sell or fund our products or services. We learn their context and pain points, what holds them back and what they aspire to achieve.
  2. Make Safety a Prerequisite - Safety is both a basic human need and a key to unlocking high performance. We actively make safety a prerequisite by establishing safety before engaging in any hazardous work. We protect people’s time, information, reputation, money, health and relationships.
  3. Experiment & Learn Rapidly - We learn rapidly by experimenting frequently. We make our experiments “safe to fail” so we are not afraid to conduct more experiments.
  4. Deliver Value Continuously - Delivering value continuously requires us to divide larger amounts of value into smaller pieces that may be delivered safely now rather than later.

Modern Agile tries to explain the agile principles to a non-technical members like customers.

Heart of Agile

  • Collaborate - closely with others to generate and develop better starting ideas. Communicate often to smooth transitions.
  • Deliver - small probes initially to learn how the world really works. Expand deliveries as you learn to predict and influence outcomes.
  • Reflect - periodically, along the way. Think about what you've learned in your collaboration and from your deliveries.
  • Improve - the direction of your ideas, their technical implementation, and your internal processes.

Scrum

Scrum can be and often is used in software development. However, Scrum itself has no software-focused elements. No software principles or practices. Scrum is defined that way. Scrum is trying to be a general way to develop products, not simply a software method.

Scrum is a framework, not a methodology, that is, Scrum prescribes roles and events, but particular processes how to implement them.

When you decide to adopt Scrum, you accept not only the practices but also the Scrum values.

Product is "discovered" throughout the development process. At the beginning, there is a vision, but not the specific details of the final system. These emerge iteratively and incrementally.

  • Product increment should always deliver a Spring Goal. Correspondingly, there are no user stories on the Product Backlog! Each of these Product Backlog slices represents some aspect of a deliverable.

Purpose is a powerful tool that can bring a team together and keep them inspired and motivated to deliver great products.

  • By focusing on accomplishing this goal and not on trying to finish all the product backlog items, we target a business-value based outcome.
  • In Scrum it doesn't matter how many PBIs the development team finishes each spring so long as they've met the spring goal.

Nothing in Scrum is designed for managing projects; rather, it is a product-development framework.

  • Scrum is a framework, not a methodology.
  • Scrum is no control tool.
  • Scrum is not faster.
  • Focus on what customers really need rather than building features nobody needs.

Scrum doesn't tell people what to do, scrum teaches otherwise: explain what needs to be done, then stand back and let the people self-organize to do it.

Teams and organizations often focus on the mechanics of Scrum and forget about their real purpose, which is usually to generate and increase value for their customers, stakeholders, and themselves.

  • If the why behind Scrum is not understood and lived, no real improvements will occur.
  • Team practices are not prescribed or fixed but are adopted and adapted a context changes.
  • Scrum implies team-owned processes rather than tool-owned processes.

Organizations should first define their challenges and where the current strategy to solve them isn't helpful or needs to be improved. They can then think about ways to overcome those limitations and explore how Scrum might help.

Agile teams don't have long backlog, but instead looks three or four Sprints ahead. Anything else is guessing. If a product can look six months ahead with certainty, waterfall probably suits better than Scrum.

The problem isn’t that Scrum isn’t a software development framework, though it isn’t. The problem might be that you’re not using Agile Software Development values and principles, or agile software development techniques to build software inside Scrum.

The biggest drawback of Scrum is its ignoring of individuals in the team. Scrum sees developers as resources, more developers better velocity, with no respect of individual skills and experience.

User Story is an abbreviated description of a feature, told from the point of view of a user.

  • User stories shouldn't propose any solution (only requirements).
  • Refactoring, architecture, code cleanup are never a story.
  • A story is always something that the business values.
  • A beginning of the story. The job of design is to solve the riddle and to deliver an implementation commensurate with the answer.

Story Points are estimated effort, not estimated time.

  • Scrum doesn't require you to estimate work in a specific way. You can use story points, PBIs count, or any other appropriate for your situation. Important is, all estimates must come from the people doing the work: the development team.

Velocity means how many story points the programmers think they can complete.

Definition of done: acceptance tests pass.

Product Owner takes business requirements and shapes a business solution that follows his vision and communicate it to the developers, who craft an implementation using tools and technologies of their choice.

  • PO doesn't maintain a requirements backlog, but rather a Product Backlog.
  • A single solution might support several user stories, but the opposite isn't true.
  • Product Backlog Items (PBIs) can be annotated with requirements, but only Product Owner responsibilities are to own the product, not only requirements.
  • Product Backlog is ordered by delivery - not priority. Mismanaged dependencies are the bane of complex development. By designing the delivery plan around delivery order, the team can easily plan to reduce dependency surprises up front.
  • PBIs may be tagged with user stories, but a proper PBI is not a story, it's a business solution.
  • "As a (role), I want (behavior), so that I get (business value)."
  • Treat the Product Backlog as a living, changing document.
  • Delete everything that's older than six months, as you likely won't ever do the work for those features. And if that work is important, it will reappear via feedback from customers and stakeholders.

Daily Scrum is an event where developers re-plan their work daily.

  • It's no reporting meeting, anything that needs to be communicated with SM or PO should be done without having to have a meeting.
  • It is a way for the team to mark daily progress and to inspect and adapt their way to delivering value by achieving the Spring Goal.

Software project is a marathon, not a sprint, nor a sequence of sprints (Uncle Bob)

The Sprint is a review-and-planning cycle, not a deployment cycle. Deploying only once at the end of the Sprint is a strong anti-pattern. [c]

Tao of Scrum

  • People
    • Product Owner decides the WHAT of the Way.
    • Team decides the HOW and HOW MUCH of the Way.
    • Scrum Master servers the Way and tells others when the Way has been lost.
  • Events
    • Planing defines what users of the Way will find of value and by when.
    • Sprints are the Way of the Team and do not vary in length.
    • Daily Standup helps the Team adapt to the Way for today.
    • Review helps the Users of the Way inspect what has been done (gather feedback).
    • Retrospective help the Team decide the Way forward by inspecting the Way that is past.
  • Things
    • Product Backlog is the Way in order.
    • Sprint Backlog is the HOW of the Way for time.
    • Spring Goal is the Way of the Sprint Backlog and the Team.
    • Definition of Done must be agreed upon by all who follow the Way.

Seven principles of continuous innovation you must follow to succeed in the 21st century

  1. delighting clients,
  2. self-organizing teams,
  3. client-driven iterations,
  4. delivering value to clients every iteration,
  5. radical transparency,
  6. continuous self-improvement, and
  7. interactive communication.

Extreme Programming (XP)

  • Stay aware. Adapt. Change.

Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The problem isn't change, because change is going to happen; the problem, rather, is our inability to cope with change.

  • The difference between what I think is valuable and what is really valuable creates waste.

What matters is not how any given person behaves as much as how the individuals behave as part of a team and as part of an organization.

Having a separate quality department sends the message that quality is exactly as important to engineering as marketing or sales. No one in engineering is responsible for quality. Someone else is. Putting QA as a separate department within the engineering organization also sends the message that engineering and quality are separate, parallel activities. Separating quality from engineering organizationally makes the job of the quality department punitive instead of constructive.

XP embraces five values to guide development: communication, simplicity, feedback, courage, and respect.

Simplicity

"What is the simplest thing that could possibly work?"

Simplicity only makes sense in context. If I'm writing a parser with a team that understands parser generator, then using a parser generator is simple.

The values are intended to balance and support each other. Improving communication helps achieve simplicity by eliminating unneeded or deferrable requirement from today's concerns.Achieving simplicity gives you that much less to communicate about.

Reflection

Good teams don't just do their work, they think about how they are working and why they are working. They analyze why they succeeded or failed. They don't try to hide their mistakes, but expose them and learn from them.

Team Topologies

Stream-aligned team

  • Primary team type in an organization, and the purpose of the other fundamental team topologies is to reduce the burden on the stream-aligned teams.
  • Aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, a single user journey, or a single user persona.
  • It's critical not to assume each capability maps to an individual rile in the team; that would mean teams would have to include at least nine members to match the list. Instead, we're talking about being able, as a team, to understand and act upon the above capabilities. This might mean having a mix of generalists and a few specialists.

Enabling team

  • Composed of specialists in a given technical (or product) domain.
  • Has the required bandwidth to research, try out options, and make informed suggestions on adequate tooling, practices, frameworks, and any of the ecosystem choices around the application stack.
  • Should exist only for a few weeks or months; there should not be a permanent dependency on an enabling team.
  • Has the mission of architecture or innovation teams, but with a better dynamic.

Complicated-subsystem team

  • Has a special remit for a subsystem that is too complicated to be dealt with by a normal stream-aligned team or platform team.
  • Optional and only used when really necessary.

Platform team

  • Provides internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services.
  • A good platform provides standards, templates, APIs, and well-proven best practices for Dev teams to use to innovate rapidly and effectively. A good platform should make it easy for Dev teams to do the right things in the right way for the organization.

Team assignments are the first draft of the architecture. [d]

Relying on individuals to comprehend and effectively deal with the volume and nature of information required to build and evolve modern software is not sustainable. Who is on the team matters less than the team dynamics; and that when it comes to measuring performance, teams matter more than individuals. [d]

A team is not simply a collection of individuals with the same manager but an entity with its own learning, goals, mission, and reasonable autonomy. A team learns and delivers together because when this happens, the results far outperform mere collections of individuals. [d]

Teams need trust to operate effectively, but if the size of a group grows too large for the necessary level of trust, that group can no longer be as effective as it was when it was a smaller unit. [d]

Instead of choosing between a monolithic architecture or a microservices architecture, design the software to fit the maximum team cognitive load. Only then can we hope to achieve sustainable, safe, rapid software delivery. [d]

The "team-sized" architecture focuses on people first, and is a more sustainable and humane approach to software architecture than either monolithic or microservices architectures, both of which focus on the technology first.

An obsession with "feature delivery" ignores the human-related and team-related dynamics inherent in modern software, leading to a lack of engagement from staff, especially when the cognitive load is exceeded. [d]

Good team

  • Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
  • Dependability: Can we count on each other to do high quality work on time?
  • Structure & clarity: Are goals, roles, and execution plans on our team clear?
  • Meaning of work: Are we working on something that is personally important for each of us?
  • Impact of work: Do we fundamentally believe that the work we’re doing matters?

Without trust, you can't have transparency.

Fundamental structural differences separate commands from teams. The former is rooted in reductionist prediction, and very good at executing planned procedures efficiently. The latter is less efficient, but much more adaptable. [a]

Team of teams is possible only if everyone knows someone on every team.

Functional safety in an interdependent environment requires that every team possess a holistic understanding of the interaction between all the moving parts. Everyone has to see the system in its entirety for the plan to work. [a]

An individual who makes a decision becomes more invested in its outcome. [a]

Enabling rather than directing: The role of the leader is no longer that of controlling puppet master, but rather that of an empathetic crafter of culture. [a]

Architects are surveying the landscape, spotting trends, helping connect people, and acting as a sounding board to help other teams get stuff done. They aren't a unit of control in this world; they are yet another enabling function. [e]

Instead of exploiting technology to monitor employee performance, the leader must allow team members to monitor him. More than directing, leaders must exhibit personal transparency. [a]

Instead of naming teams by what they do, the name should express the value they deliver. [b]

Team Interaction Modes

What is needed is colocation of purposes, not just colocation of bodies. [d]

  • Collaboration: working closely together with another team for a defined period to discover patterns, approaches, and limitations. Responsibility is shared and boundaries blurred, but problems are solved rapidly and the organization learns quickly.
  • X-as-a-Service: consuming or providing something with minimal collaboration via clearly-defined responsibilities and easy-to-consume APIs.
  • Facilitating: helping (or being helped by) another team to clear impediments, learn or adopt new approaches for a defined period of time.

Autonomous Teams

Strategy without enablement will lead to zero progress but lots of frustration. Autonomy without a strategy of feedback will resemble anarchy as teams can't judge the appropriateness of their decisions. And enablement without strategy will only make anarchy more efficient.

Managing nonautonomous teams is comparatively easy: they'll largely do as told. Autonomous teams, in contrast, require leadership.

  • Autonomous teams need better management.

Strong product teams vs. weak teams

  • Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries.
  • Good teams get their inspiration and product ideas from their vision and objectives, from observing customers’ struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers.
  • Good teams understand who each of their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that work not just for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders.
  • Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps.
  • Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside their team dares to suggest they do something.
  • Good teams have product, design, and engineering sit side by side, and they embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective silos, and ask that others make requests for their services in the form of documents and scheduling meetings.
  • Good teams are constantly trying out new ideas to innovate, but doing so in ways that protect the revenue and protect the brand. Bad teams are still waiting for permission to run a test.
  • Good teams insist they have the skill sets on their team, such as strong product design, necessary to create winning products. Bad teams don’t even know what product designers are.
  • Good teams ensure that their engineers have time to try out the prototypes in discovery every day so that they can contribute their thoughts on how to make the product better. Bad teams show the prototypes to the engineers during sprint planning so they can estimate.
  • Good teams engage directly with end users and customers every week, to better understand their customers, and to see the customer’s response to their latest ideas. Bad teams think they are the customer.
  • Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what’s on the roadmap, and are satisfied with meeting dates and ensuring quality.
  • Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough.
  • Good teams make high-integrity commitments after they’ve evaluated the request and ensured they have a viable solution that will work for the customer and the business. Bad teams complain about being a sales-driven company.
  • Good teams instrument their work so they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a nice to have.
  • Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers. Bad teams test manually at the end of a painful integration phase and then release everything at once.
  • Good teams obsess over their reference customers. Bad teams obsess over their competitors.
  • Good teams celebrate when they achieve a significant impact to the business results. Bad teams celebrate when they finally release something.

Testing

If it's hard to write a test, it's a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test.

Ideal Testing Pyramid

  1. Manual testing
  2. Automated GUI tests
  3. Automated API tests
  4. Automated integration tests
  5. Automated component tests
  6. Automated unit tests

Documentation

  • Instead of putting the expertise into Word documents, transform these documented standards and processes, which encompass the sum of the organization learnings and knowledge, into an executable form that makes them easier to reuse.
  • Ensuring that each library has significant amounts of automated tests included means the library becomes self-documenting and shows other engineers how to use it.

References

Clone this wiki locally