I think what’s missing from a lot of agile teaching material is how you build trust with your stakeholders/management. Without it whatever process you implement will still morph to have to include deadlines and estimates.
Less is more agile
91–100 of 174 posts
Re: Less is more agile
#92The only practice that I've found to be reliably agile is simply having more one-on-one meetings and less large group meetings. Large group meetings tend to waste time for at least some of the people in the group. Often, if you get 8 people together, most of the conversation is between 3 or 4 of those people, while the other 4 or 5 are bored and disengaged. One on one meetings tend to be productive since the meeting…
Group meetings, the next exponent of that is SAFe (so called Scaled Agile Framework) where you'll see 2-day-long meetings with 80+ people. I am not a fan.
Re: Less is more agile
#93I'm seeing a lot of people making Agile something it isn't/shouldn't be. There's a difference between core Agile (as in Agile Manifesto) and one of the many commercial imagination of it.
Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. It was "weaponized" by business but (at least from my experience) everything that is wrong with it was brought to the table by those business practices.
Agile isn't for planning long term projects or managing projects portfolios. It isn't a communication method not a risk management one. There are dozens (if not hundreds) of PM methods implementing full scope of PMBOK's areas of concern that one should use for those. Some even use Agile as an internal process, but still plan using other tools.
Yet, I understand many of comments here. In many places I've seen Agile is misused if not bastardized to a level where I hated it.
But just to show the contrast: I've worked recently in an environment where there was no scrum, no sprints, no agile points, and environment was really allergic to any mention of Agile (Oh no, we don't use it HERE). There was a lead who talked to everyone on Monday and said "we want to have X by the end of the week, can you do it?". Every single person had their X and everyone worked toward that goal. That planning usually worked and each week ended with deploying next iterative version of the software. It was the most Agile place I ever saw.
Re: Less is more agile
#94Earlier quoted context omitted.
Contractor is the wrong metaphor. They're building a house based on a plan already designed by an architect. Software isn't the making of a thing, it's the designing of a thing. Ask an architect how long it will take for them to design your dream home.
Architect designing home is the wrong metaphor. Buildings do not have moving parts. Their core structures are almost all fundamentally the same. There are problems to solve, but again, not dynamic systems, and always variations on very well known themes. Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. There are usually a lot…
> Buildings do not have moving parts.
Of course they do: people, furniture, water, air, heat.
Re: Less is more agile
#95The problem with this kind of article is that it doesn't recognise that software is built in different contexts. "Don't estimate" may be fine if your product is an SAAS that gets updated incrementally. It won't cut it if your clients question is "we've booked the O2 arena for April 2023. Can you build this by then?"
The problem is these clients have no idea what they are doing, they should be working out if something will be ready before booking. If they are coming to you telling you the deadline and asking if you can meet it you know your going to have problems with them. Invariably they won't have a backup for when its not done on time for whatever reason.
Yeah. The point remains though- even if they haven't booked yet, at some point they're gonna book and then it's a hard deadline. There are even cases where it's valid to come to you with a deadline: can't move Christmas, for example.
Re: Less is more agile
#96Less is more
Re: Less is more agile
#97Everything in my experience aligns with what this post states. The best teams had processes that they developed themselves, organically. However, there is a very real, pressing need from middle management to answer “what’s going on with X” when upper management asks. “I don’t know” is not an answer and neither is “we don’t know when it will be done.” These conversations ultimately control the flow of funding. So we m…
This. The people paying for a project want to know how long it will take, how much it will cost, and what the feature set is going to be. This is of course not reliably possible, so we end up with an elaborate back and forth that tries to re-impose waterfall whatever the label on the process is.
Similarly, "Individuals and Interactions over Processes and Tools" is really difficult for an organisation to cope with. Everything else in corporate land is about de-personalising and standardising the actions of workers as much as possible, so that they're interchangeable. See manufacturing lines, fast food production, call centres. "Cattle not pets", but for humans rather than servers. Once you start caring about and adapting the work process to individuals, they're not replaceable.
On the other hand, there's comfort in having a bad process. Because then you don't have to blame and confront individuals as people, just over whether they've followed the process.
Re: Less is more agile
#98Earlier quoted context omitted.
Not op but I’ve worked in Agile™ shops, places that are agile, and waterfall-y enterprise stuff. The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. Pointing doesn’t matter, extensive grooming doesn’t matter, extensive planning doesn’t matter, sprints don’t matter, etc. Grooming your work does matter but 30 minutes is enough for a high performing te…
> The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. The best project I ever worked on: one developer (me), one project manager on our side, one QA/test person at the client, and one manager at the client who was what we'd call a product owner on a scrum team. No ceremonies, no pointing, very little backlog grooming. Shared Bitbucket repo for issue…
> one developer
Someone once said to me "the advantage of a team of one is that there's only one clique and everyone's in it". I think about that from time to time 20 years on.
Re: Less is more agile
#99> Allen described his work as a consultant when he goes into a new organisation: > - First he observes > - Then he would try to identify the biggest problem > - Then he would try change it (i.e. run an experiment) > - Then if that works, run another experiment > - If it doesn’t work, go back It's probably no accident, but this is pretty close to the scientific method.
> - Then if that works, run another experiment > - If it doesn’t work, go back The problem is that if it doesn't work for a couple times, you get fired, or at least seen as incompetent. Management want magic rituals that fixes everything, not the scientific method.
> if it doesn't work for a couple times, you get fired
That is .. not a reliable description of the outcomes for management consultants, who can inflict spectacular disasters sometimes and still come out ahead. Largely because they deliver the right magic ritual.
Re: Less is more agile
#100I loved this article.
Countless times I had to estimate Jira "tickets" (actually called issues in Jira terminology) in hours. To this day, I fail to understand why and I haven't gotten a pertinent answer other than "the business needs it for planning, they're paying us, so you do it."
Yet this contradicts at least 2 Agile Manifesto pillars:
1. People and interactions over processes and tools (fostering the estimation ceremony + booking time rather than actual interaction or developer happiness).
2. Reacting to change over following a plan (plan-the-work and work-the-plan over reacting to change).
How do you even "do" estimates?! Clean Agile (ISBN-13: 978-0135781869) says "Estimates are never commitments. They are guesses."
So it seems the business is trying to get a commitment out of an estimation, at hour granularity.
What are your thoughts here?