|
The Agile Manifesto should also include "Quality Determines Profit"
|
|
|
|
|
It does include "Working software"
|
|
|
|
|
"Working" software doesn't necessarily translate to "quality" software, or even "usable" software. In point of fact, it almost never translates to those things.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
In my book it does. If the software does not do what the customer needs, then it is not working.
Luckily our product owner does get dragged into technical troubleshoot sessions now and then. That does give him a better insight into why these things needs to be prioritized.
And for any new development it is the developer working on the task that says it is done - not the product owner. So developers can guard the quality level.
Addition: And it is not the product owner that decides what refactoring is needed to add a feature as he does not have the technical knowledge. Sure he can skip the feature if our estimates including the necessary refactoring makes it too expensive.
But overall I have not been in a "war" with a product owner except once (15+ years ago now). He ran to a director, the director came to me - and then I explained software development procedures to him for half an hour. Did not go down well but not much he could say as I was right Took him a year or two to admit it directly.
|
|
|
|
|
Thanks for posting this. I was getting bored reading it yesterday. I'm glad someone else got through it to decide it was worthy.
TTFN - Kent
|
|
|
|
|
Before one can do a sprint, one should have an raw/rough overview of the route.
Only my two cents.
|
|
|
|
|
Never begin a sprint when hurdles are in place.
|
|
|
|
|
0x01AA wrote: one should have an raw/rough overview of the route. I'm afraid I have to disagree. IMHO before starting work on a sprint's committed backlog items, one should have a damn good idea of the route (i.e. the deliverables). An important aspect of the agile process (whether it be applied to manufacturing or software development) is that the deliverables for a sprint be well articulated and small - i.e. small enough so that there's a high probability of achieving the sprint's goals. Agile novices often confuse small specifications with vague specifications.
Also, you can't apply agile development to only a tiny part of the company (e.g. a development team) and hope that productivity will somehow magically improve. Where I work, product owners, BAs, QA (manual and test automation), design and documentation are involved in our agile process (along with devs) from the get go. We've actually seen improvements (requiring explicit specification of feature behaviors, fewer bugs, easier development and easier testing) in our dev cycles thanks to agile. And the tools we use aren't anything special. We just (ruthlessly) enforce good behavior: requirements (authored by product) are mostly in Gherkin and we have a clearly documented and realistic definition of done (which includes unit tests).
I may be the exception to the rule but I where I work. I think a lot of this has to with the fact that our engineering management all started out as devs (decades ago) and know the drill. #JustSayNoToBS
/ravi
|
|
|
|
|
We *constantly* redefine "done". Developers, testers and the customer all have different definitions. Then someone came up with "done done", which is "f*ckin stupid".
It doesn't help that the software we use doesn't really fit scrum/agile very well, nor does it fit our bastardized version of scrum/agile. Our con-bon board has something like 15 states.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
After reading that article -- and I read the entire thing -- my thought is:
"It is no wonder Agile is garbage. It cannot even create World Peace!"
I think everyone is reading far more into Agile than was originally intended. The corruption that has occurred to the original heart of Agile (Agile's 12 principles) is beyond discussion.
The article has, however, convinced me that all Software Development Methodologies are garbage. All! And that makes sense, because it was created by humans.
|
|
|
|
|
|
As the great J.R.R. Tolkien once wrote: "Evil cannot create anything new, they can only corrupt and ruin what good forces have invented or made."
Management can't create anything new, it can only corrupt and ruin what once was good.
|
|
|
|
|
A research team from the Texas A&M University School of Public Health has conducted a new study that found that employee and company resiliency may be enhanced through remote work "Past performance does not guarantee future results"
Your results may vary (wildly)
|
|
|
|
|
I do have a negative drop in my productivity!
|
|
|
|
|
Based on a study that was done on short term impact after a hurricane. While interesting, it doesn't address long term hybrid and remote work environments.
|
|
|
|
|
'We're at the start of a whole new era' with knowledge graphs, says Microsoft veteran Bob Muglia, akin to the arrival of the modern data stack in 2013. The graph of my knowledge is an asymptote
I think that's a math(s) joke, but I don't get it
|
|
|
|
|
Kent Sharkey wrote: The graph of my knowledge is an asymptote Mine is the turning point of y = x^2 + 42 .
Kent Sharkey wrote: I think that's a math(s) joke, but I don't get it It's so deep that explaining it would ruin the humor!
|
|
|
|
|
The Wi-Fi Alliance, which makes Wi-Fi standards and includes Qualcomm as a member, has said that Wi-Fi 7 will offer a max throughput of "at least 30Gbps" As a side benefit - warm up your lunch from anywhere in the house
|
|
|
|
|
Fine, but then they'll come out with Wifi 8, 10, and 11, and pretty soon, we won't be able to afford the hardware...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
A pair of astrobiologists this week proposed an answer to the Fermi Paradox: alien civilizations get so advanced and large that they can’t handle interstellar travel. That's a load off my mind
|
|
|
|
|
Kent Sharkey wrote: they can’t handle interstellar travel
we cannot even handle intra-business communication...
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
Keep going Glimlok there's no intelligent life down there.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
I think a simpler theory is that they only visit every few thousand years to see if we've developed a written language. When they visited in 2020 they discovered we were communicating, or at least attempting to communicate, via emojiis. On their previous visit it was Hieroglyphics and Cuneiform.
|
|
|
|
|
The Go programming language is continuing on a path of accelerated adoption and is beloved by the developers that use it. For those with their heads in the clouds
|
|
|
|
|
Communication is a key skill in today's hybrid world — making it even more important for developers to tap into the writing space. "Reading maketh a full man; conference a ready man; and writing an exact man."
|
|
|
|