We are doing it wrong – the truth about agile development
linkedin.com
linkedin.com
>sytelus: The obvious problem is that these folks prescribing the development process are not active developers.
>mmcnl: The agile manifesto was in fact drafted by software developers. Also, agile doesn't prescribe any process at all, in fact, it does the opposite. Agile in essence is quite beautiful, unfortunately it gets twisted and turned upside down until it's just another methodology (which is exactly the opposite of its original meaning).
If you are the scrum master, keep doing what you are doing. Keep coaching the development team on our core values of openness, commitment, focus, respect, and courage.
You can't use methodology (or a pointed lack thereof) to change personality.
To me, agile is endless micromanagement. Tracking every little thing in JIRA and having constant pointless meetings. The next time I look for a job, I'm going to categorically rule out any company that uses JIRA at all.
And then there's a particular quality associated with agile that just comes off as cult-like. A while back, I was googling "scrum master" to find out what one actually did, and I stumbled on the official scrum page [0]. Some of the terminology on that page just jumps out at me saying "this is a cult" (in particular, the phrase "servant-leader" is used in an almost religious sense). If someone were to state what's on that page in real life, I'd start backing away slowly. And the cult-like feel is only reinforced by the agile community's peculiar use of ordinary words such as "story".
> A scrum master cannot fail, only deliver unacceptable return on investment.
One of the best double-speak I've seen in years.
That is almost the exact opposite of agile. Unfortunately, the label "agile" gets pasted on some things that are very far from really being agile.
For this reason, be suspicious of anything labeled "agile". But don't automatically reject it - there is some real agile out there, and it's a whole different environment when it works.
Yes! Agility is largely a function of (the quality of) your code assets, so much more so than your team processes. And you can’t keep a code asset at quality unless through constant vigilance (ie, refactoring).
Now we only need to talk about who is doing the refactoring and what are their values?
We see a problem, we don't completely understand it, we think it's a problem with process but the same issues happen regardless of process, so then the issue must not be process... What's the common connection between all of this?
The complexity of code. Bugs, development time are directly related to coding style and coding technology and that is where the real issue lies.
The article author references martin fowler. Martin Fowler advocates a style of programming which makes it harder to refactor and easy to introduce bugs.
but this is not looked at by management at all. All they see is task with estimations on them. Estimations are then used to plan timelines and make a budget. It never takes into the tech defit into account. Agile projects almost always start of rosy, end up vague work never done state.
I fashioned a 90's Agile type methodology based on Release abstractions and project progress visibility.
There were always 3 Releases (MRTP - Multi-Release Technology Plan) for parking inbound feature requests from inbound stakeholders. Developers shared "minds eyes" on future releases.
Then we group scheduled integration deliverables (not activities) by Weeks. Rare deliverables were given longer extensions. Sharing a spreadsheet of weekly deliverables to the next release required enough analysis to share the schedule abstraction.
Going dark was impossible. Everyone documented short "So Far, More To Go, Defer It" lists with short rationales similar to version control commit comments. We could push schedule breaking "features" to future releases. Every Thursday was integration and retime boxing of the schedule. The dev notes were collated into report "Weeklies." In practice, more continuous integrations were daily to his weekly hard integration targets.
The methodology started with a workbook of about 15 product planning exercises from User "day in the life" to "operational cost estimate" spreadsheet formalisms.
In practice developers shared a subset of the planning formalism "intermediate representations." But all stakeholders (business too) were fully aware and SIGNED ON to every planning step skipped for schedule or cost necessities.
It was very ritual high visibility human applied "design by contract." We had a perfect execution record on early Linux tooling with teams from 2-15 (Product Planners, Information Architect, Soft Devs, System Architects) on about 125 high pressure engagements. Most was a mix of Java Servlet, SMTP and C telecoms projects. We had to write our protocol handlers back then on shifting sand.
I might write it up as "The Adrenaline Way." It doesn't easily apply to individual, exploratory or Kanban content "journey without a destination" project teams. But it applies well to products with inbound and outbound marketing teams involved.
I cannot disagree more with this. You should make decisions as soon as you have a minimal amount of data. If you keep waiting the last possible moment, you will get a product that is the product of the least possible time.
If you make a decision too late, you have 100% failed.
Customers see it as a really fast, transparent and easy way to run projects
Project Managers see it as a way to keep track on a projects at a high level view and mostly for metrics and reporting
Project leaders use it to assign tasks to minions
Minions see it as a way to work independently without looking at the big picture.
Who is looking at the big picture? nobody. that's why agile fails.
"the body of knowledge in those tomes" threw me off - quite the opposite of Rework.