What's the point of saying we're doing agile software development if we don't get the heart of the idea right? For example, reducing risk through continuous deliveries (decreasing the feedback loop).
Do you want something to become fashionable in the industry? start charging for certifications. Have you ever seen any extreme programming certification mafia?
Agile software development is the best risk management system we know. Estimates are a risk for the client, choose continuous delivery and evolutive design.
Abstraction adds complexity, when it solves a problem i'ts ok, but when is just accidental complexity (example: unnecessary interfaces, when a class has just one implementation) we are increasing the cost of the feature (Fundamental Theorem of Agile Software Development).
Why agile teams realy need to understand agile development? because they have freedom to choose how to work, if they don't understand agile development, they can get in troubles.
If you have slow feedback loop, you can lose trust from your team and you may want work about work (like Scrum dailys).
Why big teams doesn't work? (not exactly teams but groups of development, you can have a big team but with smalls groups of development)
Agile software development implies connection with product/client. The bigger the team is, the greater the likelihood of only some of the members be conected to the value to be delivered. Even if only a few members of a little team will develop a feature, all the team need to understand the value.
Delivery processes of large teams tend to be Taylorist instead of agile. There will usually be something like a backlog (created by some manager) and the members will do the tasks without customer interaction and not even understand how it adds value to the product. This also is bad for continous delivery.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (Agile Manifesto)
We must assume that the engineer takes exactly as long as he needs to finish a feature. There are technical or business difficulties that can impact delivery time, but these are obstacles that we cannot avoid.
What causes delay in development are frictions caused by the environment and the organization. These frictions must be observed and eliminated.
Agile is not a time-driven development method.
SQUAT = Status Quo Using Agile Terminology
On remote environment, create open rooms to instigate the teamwork
Author perspective is a illusion, does not make sense. You cannot really expect a third person who's never been involve in any conversation about the work done by the pair, who hasn't participated in the thinking process that led to that code, who hasn't discussed the intricaies of a solution, to be able to jump in at the end of development and give any productive advice. And if any productive advice is given, that's a waste, cause it's happening too late.
If something is slow, stressful, or awkward, transform it via safety and speed.
What activities are you or your customers forced to perform today that are slow, hard, and ungraceful? What product or service could you invent that would give you or your customers the superpowers to make those same activities quick, easy, and graceful? Help people be agile by removing the stress and mess of slow, hard, ungraceful experiences.
How often do you or your teams spend time with actual users or customers? What could improve this collaboration? Bring together people who can identify and solve problems. Close, frequent collaboration increases agility.
Traditions are hard to break. Many people who learned how to perform a skill years or decades ago use the same technique when teaching others. They are stuck in a traditional mindset, unaware of new, innovative approaches that help us establish balance sooner; drive out fear more effectively; and make it quicker, easier, and more graceful to learn a new skill. Don’t just blindly follow long-established approaches when learning a new skill. Explore alternatives that accelerate learning.
I love to collaborate with others to discover bargains: high value at low cost. Bargain hunting is an opportunity to be agile by considering several approaches to solving a problem and discovering a suitable solution that is both efficient and effective. Are you regularly considering your options? To be more agile, consider at least three options.
Stop hurrying, find balance, and learn quickness under control. Be quick—but don’t hurry.
A siloed team tends to focus on its own work and doesn’t collaborate gracefully with other siloed teams. When an organization needs work to be done across silos, you end up with slow handoffs—one silo waiting a while for another silo to complete work.
Teams that are truly agile work quickly and easily and have few to no slow handoffs.
They are composed of the right mix of staff (something we call a “balanced team”) to enable high-speed value creation and delivery. Two of the most agile teams I’ve ever worked with were not small. One team had sixteen full-time people (and several more part-time staff) while the other had thirty full-time people.
• Remove one slow handoff at a time: Look for one slow handoff and remove it by inviting an external person to collaborate (even temporarily) with your team. Repeat for every slow handoff. • Insource slow dependencies: For any slow dependency, find a way to insource it completely rather than outsourcing it to another team. • Make the slowness visible: Calculate and visualize the time wasted while waiting for slow handoffs to complete. Use metrics and visualizations to catalyze a change toward a genuine, balanced team. • Limit work in process: While a team is waiting on other teams to complete work, it often begins new work. This leads to lots of work in process, with little getting finished and delivered. Limiting the amount of new work that may be started before current work is finished is a way to bring more attention to the bottlenecks resulting from slow handoffs.
Respond rapidly to people. It respects them and rewards you.
There is a big lack of education in our industry, example: "I need estimates because i cant invest 1M without know if it will works in one year" R: "If we do something in 2 weeks to you see if is right and we can adjust, go to the next thing and do the more important things first" "It will be great!"
Agile: 1 - Marked by ready ability to move with quick easy grace. 2 - Having a quick resourceful and adaptable character. An agile entreprise is one that has achieved a level of operational excellence that enables it to make changes at the same pace that it discovers a need for them (Tim Snyder)
Agility is a business strategy
- It is not a process or methodology (but there are process that can help) It requires a suitable culture Becoming agile change all the levels of the organization
Story: A narrative that takes a user through some process that results in a valuable outcome.
Risk management: Big batches = more risk, small batches of evolutive work = less risk
WE LEARN AS WE WORK
Cost of X days of delay or rework: Direct costs(like developers) + opportunity cost (no working in the right thing)
Time is money Cost of delay Cost of rework Cost of defects Cost of communication Deliver early, deliver often
Trust and empower the people who do the work
Is better to solve a small critical problem now than deliver something perfect in a year Use thin vertical slices.
Plan around value, not time. You dont need estimates, you need to deliver the most important thing to you customer. To know the more important thing, talk to your customer and develop a culture of experimentation and learning
Plans need to change as we work. Its a example of what can be, not a prediction of what will happen.
People fail to understand that needing to know something doesn't make it possible for the knowledge to be made available. Forecast != Estimate (not scientific language) - We use events of similar nature (stories of size 1, defining size 1 through estimates) with Monte Carlo method to generate a forecast. Trying to predict events of a different nature from stories will generate a higher % error, given the non-standardization of time for items such as bugs.
Starting from the premise that people work at a sustainable pace when they are working on things that are not urgent like bugs or delayed deliveries (defining sustainable pace as something perceived through our experimentation). If they do not work at a sustainable pace, the likelihood of structural problems (layoffs, decreased quality in production) becomes greater.
Therefore, there is a standard work rhythm for normal deliveries, it does not mean that this is an optimal qualification between performance and sustainability, but it is a phenomenon that exists. If this is not happening, we are dealing with personal/individual problems (such as excessive procrastination) or a lack of ethics/commitment, but the solution to these problems is different.
From this point of view I always assume that things will always take exactly as long as necessary to be done, it is obvious that there may be situations where when planning is too loose people unnecessarily slow down, but this is a side effect of PREDICTION
Separate categories: Bugs that depend on impact may have top priority and should be resolved as quickly as possible at any cost Resources with data fixation (generally for strategic reasons for the company) disable more detailed monitoring of progress so that we know if we are late, we recommend taking some action such as overtime or giving up certain features or quality...
Features without a fixed date, which have a forecast, the forecast date cannot be used as an instrument to rush the development process unnecessarily, if so, we will unintentionally use rigid timeboxes (such as sprints) and will consequently harm the effects of having a data correction for everything.
Everyone is obviously an adult and knows that this does not mean that performance should not be demanded, but rather understand that (ATTENTION): The delivery date prediction mechanism is the one that must adjust the delivery date. And there are no people who should rush to get the engine's prediction data right at any cost.
Obviously observing the particularities of the demands (whether there is fixed data or not) and the impact of the specific ones on the company's roadmap. There may be situations in which the company finds itself hostage to the forecasting mechanism and needs to accelerate a certain delivery: example: Delivery date set for the 15th, if delivery if there is a risk so close?), but it is a specific situation, it is another story, I am speaking in abstract terms.
Concluding:
1 - Forecast data should not be used as a way to rush the development process without a real need for the company.
2 - If the forecast is frequently wrong, what should be adjusted is the forecast method.
3 - If productivity is low it must be increased, however this conversation did not focus on this merit but rather on the function of the ability to predict delivery data.
develop: https://www.youtube.com/watch?v=WSes_PexXcA&t=1s dora metrics xp book