welcome š¤
May this page spark joy and make you and your team thinking and discussing about certain aspects in software and product development.
š leeeet's go š
relative estimation
Story points only work for relative estimation. For a junior dev, the difference between a 2 point story A and a 4 point story B means double the work. For him that could mean 3 days for A and 6 days for B. For a senior dev in the same team, it also means double the work. But for her its 1 day for A and 2 days for B.
With relative estimation, the predictability comes with stable teams and the amount of story points they delivered in the past (which also reflects the average amount of distraction). It is NOT comparable between teams.
If you need estimates (for trade-off decisions, not for comparison!) in the unit hours, days, or weeks, estimate in hours, days, or weeks. And use the Fibonacci sequence for that (...2 days, 3 days, 5 days, 8 days, ....). With that you prevent discussions about small differences and reflect the increasing uncertainty of big stories.
I like to say that I may have invented story points, and if I did, Iām sorry now.
PS: I love to talk about animals rather than story points. You may want to try this at home: Magic estimation in the zoo
continuous planning
When the next PI Planning is arriving, everybody gets nervous and has to prepare this holy event, specify in detail possible features, and try not beeing confused with the terms PI objectives, outcome and features.
Thanks to the PI Planning Business and IT are forced, at least 4 times a year, to talk to each other.
But: How often we should plan is driven by the context of our product. A new fancy app needs another cadence and a different kind of planning then a core business application with 100 interfaces.
And do not forget:
"Everybody has a plan until they get punched in the mouth"
"Business people and developers must work together daily throughout the project."
Thank you, Pirmin, for the inspiration!
wall of confusion
The underlying success factor to meet a common goal is culture. No tool and no process has the same leverage effect.
Since DevOps it is apparent, that Dev (the folks who want to create value - features - asap) and Ops (the folks who want to have secure, stable, maintainable, ... software) should work together to be able to deliver as fast as needed secure, stable, maintainable, ... software.
To do so, we should tear down the wall of confusion first.
Read more: DevOps Culture (Part 1) - IT Revolution
quality addiction
Andres Freund made changes at the open source database PostgreSQL.
He made a performance test and noticed a delay of 500ms within the remote login ssh-processes.
While searching for the root cause he and the community found a serious security vulnerability.
agility with frameworks
Agile software development is a cultural and mindset thing.
A framework or parts of it may help to become agile .
But be aware: Sending employees to certification courses and organising PI plannings must not mean, that you are agile.
hiding behind a framework
Hiding behind processes and frameworks is easy.
"I can't do that for you, the next PI planning is only in 10 weeks".
Beside all rules don't forget to collaborate! Individuals and Interactions over Processes and Tools (even if the tools are cool).
devops - infrastructure and culture
With a change, we want to "Earn or Learn".
Do our users like the new feature? Do they miss the dropped feature?
To figure this out you need a fast time-to-market, because only the market (internal users are kind of a market too) tells you the truth.
Doing DevOps means, creating the infrastructure AND culture to handle a faster time-to-market.
boring solution
"Use the simplest and most boring solutions for a problem, and remember that 'boring' should not be conflated with 'bad' or technical debt." GitLab
And for that you have to (really) understand the (underlying) problem!
feature trap
We mostly get measured by the amount of features delivered. And because you get what you measure we deliver features without having any idea, if they fulfil a purpose. We should focus on the outcome instead. Maybe redesign a feature. Drop one. Or increase the maintainability of your product to reduce the costs of future features.
Recommended reading: Escaping the Build Trap
feature flags
With DevOps techniques, we can separate the continuous deployment to production from releasing functions to the users. With feature flags, we can hide a feature from all users and e.g. release it only to a few test-users.
mvp or prototype?
While both serve the purpose of testing a hypothesis and gathering feedback, an MVP has to survive in the market. That means it has to generate a return on investment with as low risk and effort as possible.
Read more: SyncDev - MVP
dealing with stakeholders
"The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner." Scrum Guide
The purpose of a Product Owner is to have a single instance who takes decisions about the product. That means she/he or a small group of people must have the power to do so but also have the responsibility about the outcome. For that, strategy and vision of the company and the product have to be clear!
quality is fix, scope is variable
In traditional project methodologies, scope and (most of the time) quality are fix.
Cost and time are expandable, which leads to many project delays (because we do not know everything at the beginning).
In agile software development practices, the scope must be variable! Cost (a team), time (an iteration) and, most important, quality are fix!
I would rather have two out of five things "(really) done", instead of five things "almost done". With that, the "done"-things can unfold their effects.
mvp as an excuse
An MVP is NOT a collection of a small number of in-depth features. In its origin, it is a marketable product with enough features in width, each of it as simple as possible.
"(...) the minimum viable product is a test of a specific set of hypotheses, with a goal of proving or disproving them as quickly as possible. One of the most important of these hypotheses is always: what will the customer care about? How will they define quality?"
Good enough never is (or is it?)
Good enough never is (or is it?)
shiny facade - technical dept
Error culture does not mean sloppy work.
The opposite is true. We all must encourage and help each other ensuring quality and not taking on debt we can't pay back.
Technical dept is a credit we take on as a team, which we have to pay back including interest. With too much credit, we are no longer able to pay our bills for the basic needs (which are in the context of software: creating value).
pareto vs. mvp definition
The lower definition comes from the inventor of the MVP, SyncDev. The upper expression is the widely known Pareto principle.
In the end the message is: Good is good enough.
Of course, this is not true for every case, but for most cases (let's say for 80% š).
simplicity
Understanding the to-be-solved problem and find a solution as simple as possible saves you energy and costs on the long run. Your product will be easier to understand, easier to maintain and easier to extend.
"Simplicity - the art of maximizing the amount of work not done - is essential." Principles behind the Agile Manifesto
Read more: Gene Kim - The Five Ideals of DevOps
commitment
Do not make compromises in quality to get the s*it done! You may win the sprint, but will collapse during the marathon.
The only Definition of Done (DoD) you need:
- Is it the highest quality code we can build, knowing what we know now?
- Are the users happy with it (which you can't know until they're using it).
- Does it satisfy both our and the user's/customer's strategic goals?
That's it.
Allen Holub
The only Definition of Done (DoD) you need:
- Is it the highest quality code we can build, knowing what we know now?
- Are the users happy with it (which you can't know until they're using it).
- Does it satisfy both our and the user's/customer's strategic goals?
That's it.
Allen Holub
working software
Working software does not mean doing everything. It may be a good idea to scratch and discuss an UI-Flow. BUT the PRIMARY measure is working software or a valuable product, respectively.
testing in product development
Imagine: 15 developers wrote software for 6 months. Afterwards they were allocated to other projects. Maybe 2 or 3 stay for bugfixing. The software reaches the test-team, not yet been involved into the project at all. Now they have 4 weeks to test the whole thing (the plan was 8 weeks but there were more feature requests so the development took 1 month longer and because we have to stick to the deadline the last phase - testing - is shortened).
This still happens too often in the "agile world". Stop it!
Instead embed testers, quality mindset, Test-Driven-Development, Test-Automation etc. into your team and work together! Testing is NOT a phase! It's an inherit part of software development.
build-measure-learn-(adapt)
The concept of a MVP gained popularity with the lean startup methodology. The lean startup methodology states that you should "Build - Measure - Learn" (B-M-L). Based on the learnings you decide to pivot or preserve. Therefore without measuring and learning you'll miss the whole magic.
Oh, and it doesn't matter if you B-M-L one feature or a whole product. Use it as a thinking model.
Read more: The Lean Startup Principles
a product is a series of mvps
"Because no product is ever "done", you create a series of MVPs, one after the other."
Mc Greal, Don; Jocham, Ralph - The Professional Product Owner
Mc Greal, Don; Jocham, Ralph - The Professional Product Owner
product increment
If we stick to theory (which sometimes helps to understand the motivation behind a concept):
"The moment a Product Backlog item meets the Definition of Done, an Increment is born."
"Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value."
We do not have to release everything immediately. We do not have to wait until the end of the PI or Sprint. Feature Flags (a.k.a. Feature Toggles) or Canary Deployments help to decouple deployment from release and reduce the risk of releasing buggy code (heck! we can't prevent this 100%).
Read more: Martin Fowler - Feature Toggles
