Less is more agile
beny23.github.io
beny23.github.io
If you are implementing a set process from a book you are by very definition anti-agile.
When I implement agile at companies I don't even call it agile. And the only initial practices are:
* transparency -- you can't fix what you can't see
* improvement loop -- you need to learn from your mistakes and feed the results into next cycle
* process building fundamentals -- once you learned you need mechanisms to preserve the results. Checklists, templates, documentation, automation, infrastructure as code, etc.
Everything else is result of the learning. As we go, we spot problems or improvement opportunities and we decide how to fix it together. A lot of these fixes come from agile literature. Nobody said you have to reinvent everything. But now that we have implemented it in response to our actual problem we know why it is there which is way better than just implementing it without understanding.
Along the way people learn they have power to change things in a realistic way and not only they are welcome to do so but it is actually their job. Which is exactly the goal of all of this and yet completely missing when you put forward a book and say the process has to be implemented exactly as in the book.
Plan, act, reflect in practical terms. Build, measure, learn in lean terms. Vita activa, vita contemplativa, and sensemaking in academic or philosophical terms. Alistair Cockburn, Allen Hollub, and Bonita Roy in software terms. It’s all a cycle.
It doesn’t matter which page from which of those playbooks you take from on any given Sunday. They are remarkably consistent.
The observation I’ve made is that friends who succeed at this deftly avoid agile cliches and their teams are focused and efffective while checking all the boxes from crystal clear or spolsky’s list or accelerate.
This points to the fact that agile has become the cargo cult dogma it set out to replace twenty years ago.
> feed the results into next cycle
Right, so you have a concept of cycles; in scrum these would be thought of as sprints (larger cycles) or single days of work (smaller cycles)
> transparency -- you can't fix what you can't see
Yep. In scrum, this would would be addressed by daily scrums (transparency and coordination on a daily basis), sprint reviews (transparency about the finished cycle), sprint planning (transparency about the next cycle), and sprint retrospectives (transparency about the way the team works)
> improvement loop
In scrum, that would be sprint retrospectives with a commitment to attempt to address at least some issues raised during a retrospective in the following cycle.
> once you learned you need mechanisms to preserve the results
In scrum, those would be backlogs (for the product and for the sprint). The practices specific to software engineering, such as automation, infrastructure as code, etc., fall out of the purview of scrum and will be picked up by other engineering practices (CI/CD, version control, etc.)
Rather than focusing on the team, its own alchemy, its work and the very specific nature of the work.
The process should adapt to the people and the work at hand. Not the other way around. That's the very ethos of the Agile Manifesto. Scrum is used in corporate environments as the exact opposite.
Scrum, as defined in the Scrum Guide, is perfectly consistent with the Agile Manifesto. It is one of the ways of putting the manifesto into practice. Scrum's framework clearly promotes interactions between individuals, customer collaboration, working software, and response to change. If individuals, who, according to the manifesto, are more valuable than the processes, decide that the processes defined in scrum aren't working for them, they are always free to reject scrum and work out another set of processes. But if a team doesn't yet know what processes would work for it, scrum is as good a place to start as any, to actually feel what enacting the manifesto actually involves.
No, it's not. It's a very bad place to start. Because Scrum is a fixed process, with a fixed meaning.
If you started with Scrum and then stopped doing sprints because they weren't working for your team, you would quickly run into all sorts of opposition around "we're not doing Scrum properly; we need to be doing sprints".
Whereas if you started with nothing, no process at all, and later tried adding sprints, everyone would evaluate sprints by themselves with no preconditioned notion of how that should work within the rest of the process.
I completely agree. The reason I think it's a great place to start though is because this fixed process, with its fixed meaning, is well suited to the work involved in building new products.
> If you started with Scrum and then stopped doing sprints because they weren't working for your team...
...then you would stop doing scrum.
The objection "we're not doing Scrum properly; we need to be doing sprints" would only make sense in the context where you would be pretending to continue to be using scrum after throwing parts of it away. The moment you stopped doing sprints, you have made a decision that scrum as a process isn't working for you, and have switched to something else. You shouldn't keep calling it scrum to avoid confusion.
It is not because it specifically mandates a given methodology imposed upon a team.
The ethos of the agile manifesto is precisely the opposite.
And Scrum might be a good place to start with in theory, while in practice, it's become in many corporations as the standard way of operations.
It's "what everyone do". It's the "best practice". It's also become a huge red flag for hiring, still few company realize that yet.
Just like any shoe you find in a store might be fully functional and useful to somebody it might just not be good fit for you.
Now, that might not be a problem for a more traditional development process of the past. In the past we would just choose one of the prescribed processes that was deemed the most fitting.
But the agile came and basically said that any set process is by definition wrong. The goal was to pursue constant improvement, forge the process as you go along and the idea was that the company that can improve faster will, over time, prevail over competition (you can't say "win", because it is an infinite game). And that the faster you can execute the iterations of these improvements the faster you can improve overall. And that the higher management is usually ill suited to do this because it just takes too much time to get the improvement iteration and that they usually don't know the specifics anyway.
And out of all this came the idea that the team itself should be responsible for improving their own process because this is the only way to do it fast enough.
In practice when the team notices a problem I may offer a possible solution for discussion and this solution will frequently be something already known from typical "agile"/scrum/kanban literature. Again, not saying it is all wrong but it needs to be viewed as a collection of solutions to individual problems rather than collectively a solution to fixing development process.
> It is not because it specifically mandates a given methodology imposed upon a team.
You are misreading what I have written.
Yes, Scrum specifically mandates a certain set of practices. However, all these prescribed practices are aligned with the agile manifesto. The manifesto never said be anarchic. The manifesto never said do not follow any processes in your work. If that were your understanding of the manifesto, you would have to object to all and any processes that have any predefined structure to them. Code reviews? Nope, that's a process. Pair programming? Nope, that's a process. TDD? Nope, too rigid. And so on.
Scrum is A way to put agile values and principles into practice, not THE way. But it is certainly not antagonistic to the manifesto.
> And Scrum might be a good place to start with in theory, while in practice, it's become in many corporations as the standard way of operations.
I am re-reading this sentence, and the previous two paragraphs, and just can't connect them together into a coherent thesis. Scrum is a good place to start in theory? — Well, yeah; that's what I've been saying here. — But in many places Scrum is practiced atrociously? — Well, yeah, don't do it atrociously then; do it properly.
Daily Scrum, Sprint Review, Sprint Goal, even the role of Scrum Master - depending on the team, some or all of these things can be removed to the benefit of the team, but Scrum itself doesn't allow it. It's either all or nothing, which is why I believe Scrum itself is anti-Agile.
Of course it doesn't. It wouldn't be scrum if these were removed; it would be something else. Which is fine; but if you prefer to organize your work in a way that isn't scrum, then why would you call it scrum?
> It's either all or nothing
Isn't it the same with everything else? An agile manifesto, but with only one value rather than four? TDD but with tests written after the code, and without refactoring? And so on?
Agile is an idea, a concept. Scrum is a tool (or even a framework, according to its website), and for a tool that's associated with a concept of being agile and flexible, it's incredibly rigid.
The point of agile is to teach your team to solve problems. To build ability to spot whenever something can be improved and then understand what is expected of them and the tools at the disposal.
An "agile from a book" is just a set of answers to some common problems. Your team will be none the wiser about how to deal with other problems that were not addressed by the book author.
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 make up these elaborate games to create guesses for these conversations. Sometimes the guesses are close, other times not.
I don’t know what the answer is, but there exists a gulf between what developers and managers need. Both needs are equally valid.
> I quoted the First Law of Mentat at her: ‘A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.’
Managers rellying on dashboards and reports only to know whats going on in their teams, have always teams oerforming sub par. And they aren't able to answer upper management questions any better.
If they can't understand that stuff they should not be making decisions.
But basically it's a list of stuff done, with proof, and stuff left to do.
Then they can see the progress bar moving and make decisions based on that. To get estimates, ask for explanations of what is involved in the remaining steps. Again, they should have technical competence to get a rough estimate from those reports.
That doesn't seem right. As a developer, if I were the CEO of a company, I would not be able to read progress from the legal team, or finance team, or any other team. What's going on with that lawsuit? No idea. Do I know how long it'll take to wrap that up? Nope. I can't understand any of their jargon. I still gotta make decisions about it.
I don't need legal competence in order to run the company or make decisions about stuff, and I shouldn't need technical competence either.
It's on us, as developers, to communicate clearly and give answers and reasonable estimates, so management can make their plans and adjust priorities if necessary. The process we use to generate those answers (agile, git commits, deployments) is entirely up to us and could not matter less to the business, at the end of the day.
In a small organization, the reality is that many hats must be worn. That may mean developers play manager to some degree, but also the CEO must be prepared to step into the trenches.
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.
> 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.
Certainly … if they’re “doing it wrong”. :-)
Do VC know any of these things? The agile approach, YC, and the SAFE are predicated on these being unspecifiable to any signficant accuracy.
So a better approach may be to:
1. Change the money process from budgeting to investment.
2. Fund capable teams of dedicated fixed capacity, and you can nail budget to the penny.
3. Then, fund by mix of ROX/ROE/ROI* on prioritization of the backlog, and you’ll get out of the team what you chose to fund as the team capacity.
Done.
* Return on Experience (NPS etc.), Return on Equity, Return on Investment. And consider sharing something like “Implementing Beyond Budgeting” with the money people:
https://smile.amazon.com/Implementing-Beyond-Budgeting-Unloc...
** To maintain trust with the money people, engineering cannot employ unproductive teams. It may be the tradeoff for engineers from a terrible budget driven process is better job security, since their individual performance or abilities to output great features matters less to the corporation than the estimation/budgeting/CYA processes do. In the budgeting world, senior executives get rotated out faster than IT teams.
What's missing here is that this doesn't come for free. Requiring to always be able to get information about "what's the progress" without delay means that someone must constantly calculate the current progress. And this is difficult and requires a human that can estimate all the things, including resources (will a dev get sick next week?) and delays from other teams, external blockers and their chance of happening (will the clould environment fail again this week?) and so on.
If this is desired (it may well be) a resource for this has to be planned and implemented _in advance_. That costs a lot of money. And even then, it can just give an estimate in the form of a probablity curve.
If the management has not planned for this, they can either not expect to get status information all the time but have to request it, then wait for it to be calculated and have to accept it will delay the project by the time it takes to calculate it. Or they have to live with an extremely vague and unprecise estimation.
And unfortunately, all methods, be it SCRUM, v-model xt or a randomly assembled method, will not automatically calculate a good estimate. Otherwise no one would complain. :)
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.
I wouldn't describe it as such. Such descriptions are how managers got the idea they can put development teams into their bubbles while restricting their access to assets required, demanding they go through multiple layers of management to get simple things done. Ideally, you don't just have a response, but the power to change things more efficiently.
Case in point: devops, CICD. Most teams would benefit from having their own CICD. Many companies silo a separate "devops" team and multiple development teams, while pipelining the demands of dev teams from manager to manager. "Devops" team gets swarmed by status pings every day, development teams are annoyed because trivial things don't get solved, management gets annoyed because "why is it taking so long?". And the team could easily teach someone the basics and get their test environment running.
Of course, above scenario requires management gives the power to change things to more people. Management in general thrives on lack of trust, so that's a no-no. "We love agile!", they say. Yes, when the teams get nicely silo'd and somehow become "more predictable", but are still as powerless as before.
As to CI/CD pipelines: I think a centralised devops team that blocks everyone is as much an anti pattern as a wild-west approach where 3 teams operate 4 different CI/CD tech stacks. There is much to be said about building a platform (when the size of the operation is big enough to warrant it) and using golden paths or paved roads.
I have only worked at AWS and all teams here completely own their deployments and operations. I thought this was how everyone does it.
It creates a lot of friction and bottlenecks, while keeping developers from improving.
Everyone that has any sense, yes.
Any company with a legacy ops/dba/it team? No. These people are now called devops because it’s trendy, and they have too much political capitsl to suddenly get rid off (plus such fun things as thinking devs are too irresponsible to touch prod).
This is kind of expected. Agile was always very vague about what it was from the get go. At this point it's like "god" or "love" - there is no one shared definition and never will be.
Rather than arguing over what really is is or should be we should just be quietly deprecating and using a different name for what we think it should have been all along, making an effort to be specific this time.
XP was specific and good for the time it just... stayed at version 1.0 forever.
Any other flow in which management wants to standarized the process, fails at agility. I don't consider those Agile. Just because I call the fruit Orange Blue, doesn't make it so.
At $WORK we are agile as a software team, but we don't practice Agile. It's a subtle but important difference imo.
Unfortunately the word "agile" has picked up some baggage over the years that means to many folks the word translates into a rigid framework of practices, philosophies and ceremonies. This to me is the total antithesis of what being agile really means.
At this point, we could very well stop using the word agile because if nobody knows or agrees on its meaning, it became a meaningless word.
I understand your point about agile vs Agile but we can't rely on people (not) putting the upper case A at the right place, and even on agreeing on the meaning for these words.
> - 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.
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.
This can however work in places that are (truly) leadership focused where you A) fail fast and B) clearly outline your intention to accept failure as part of the process of improvement.
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.
Unfortunately, Agile quickly turned to be even worse than what preceded.
Corporate bureaucracy should be fought against at all times and by all means.
If you work in software, you are valuable enough to have a say, and a choice about who you work for.
Not everything has to turn into a bullshit job.
creative work requires a different environment than widget-making.
> Individuals and interactions over processes and tools
This makes it seem like processes and tools are not important. But when you get beyond 5 or so people working on something, processes and tools are absolutely critical. There is no contradiction between processes and tools, and individuals and interactions. Better processes and tools will enable better interactions between individuals and will allow those individuals to influence the larger team.
What this should have been is something like:
Individuals and interactions <=> Processes and Tools
Both feed into each other and should be improving each other.
Flat hierarchy is an other kind of bullshit, clearly established leadership is important.
When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them.
Most of the bureaucracy problems are magically going away when middle management is gone.
Middle management is just nepotism, where incompetent/not-caring managers hire from their network to gain power.
That ia a mjor difference between Amazon and most other places I worked at. Amazon management actually did things beyond managing. There are some of the managers in places as well, they are a minority so.
All of this being said this puts a lot of pressure on product managers because it’s hard for them to express how long something will take. The key here is that even if you do all the ceremonies you don’t really know how long it’ll take anyway.
The only way you can work like this is if you have built up trust from your PM. If you can throw all of the shit away and give the PM what they want they’ll go to bat for you. For agile to work there has to be an incredible amount of trust that every team member is going to do what they say. And the lack of trust is when you get Agile™
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 tracking. Deployments scheduled every Tuesday when their QA person signed off on the feature working as expected (this was in the days before CI/CD became common).
Worked great. Low friction, they got features and bug fixes, we didn't get hassled, and we could set up a call (or usually just a couple of emails) if we needed clarification or needed to explain why something was more complex to do than we or they originally thought. One of the best six month periods in my career, and I've been doing this stuff for almost 25 years.
I don't mind some aspects of scrum, but the things I don't mind (mostly around team autonomy and self-organization) seem to be the same things that are quickest to get thrown out when someone gets impatient.
My last job had me on a ten person developer team and I would not try to use that process there - although I'd consider splitting that into a couple of smaller groups focused on a specific product/system and using a very lightweight process for those groups.
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.
When you take it back to its roots and cut out all the Scrum or SAFe nonsense and adapt it to your team it can really work.
Note, I’m not saying estimates are bad per se and can imagine teams for whom it does work, but it would have to be something that the team is happy with not an impose-from-above methodology…
I've known managers who say "Group meetings are great because I get to meet with everyone at once and it saves me so much time!" But that only benefits the manager. Meanwhile some of the people in the meeting are just sitting there, killing time, bored, waiting for the manager to have 10 minutes to talk to them. By contrast, more one-on-one meetings, even if only for 10 minutes, allows everyone to be involved during the moments when they need to be involved.
When we criticize some of the rituals and bureaucracy that has become associated with the word "agile" most of the time we are criticizing group meetings. That includes the daily standup. I've run teams successfully by having quick one-on-one 10 minute meetings with everyone on my team, everyday. But I rarely feel the need to get the whole team together. In fact, when I'm leading a large team, I never need to get the whole team together, it is always some smaller subset that I pull together.
If you are the team leader, then you need to think carefully about who you need to talk to for any given purpose. If you have the discipline to only talk to the minimum set of people you need to talk to, then you are freeing up a lot of people to keep working on their real work, since they are not in a meeting with you.
1. If the people on the team can't change the process, it ain't agile
2. Sprints aren't a failure of agile, they're a failure of devops. Once you start deploying multiple times a day, nobody will care when one sprint ends and the next begins and it'll be fine
3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular than months
Separately from deployments, in some less-than-ideally run organisations, management may whimsically change its mind about what the number one priority is from day to day. Two-week sprints can shield the delivery team from this, by acting as some kind of low-pass filter on thrashing priorities, to create space to get a few things entirely done.
Five years ago, we deployed once per sprint, and it was a big deal: the test pass takes this many days, the change management team needs this much time, etc. So quite often, finishing a story on day N might mean it goes out on day N+4, but finishing it on day N+1 means it'll take two more weeks, day N+18. That's where the urgency came from: that "tax" of lost time due to infrequent deploys. So there was a lot of pressure to get things into a given sprint. Hence, sprint commitments.
Now, on the same platform but with frequent deploys, we still have pressure to get a story done by a certain day sometimes, but the sprint cadence no longer affects our ability to do that. It goes when it goes. Without that pressue, we realized that sprint commitments didn't serve much purpose, so w stopped doing them, and we haven't missed them.
That's what I was referring to - it's not the sprint that matters, it's the "tax" on deployment time, which varies depending on where you are in the sprint. Take that away, and you stop caring where you are in the sprint, like a teenager in summertime losing track of the days of the week.
The motivation to batch releases was largely driven by a desire to do full end-to-end integration testing of changes between a number of entangled backend and frontend systems. It often took days to stabilise all the components in the single pre-production staging environment used for end to end integration testing, then run through the test plan. Perform batched end-to-end testing of system was the process bottleneck.
Monthly releases created similar crunch dynamics of changes being delayed by a month if they weren't stable enough to enter the monthly test cycle. Since end to end testing is the bottleneck, you don't want to feed in low quality inputs (rushed changes that are likely to cause issues and then trigger re-tests of the entire slow end to end test process).
I'm not saying this is the best way to do this, it definitely isn't, but there can be some reasoning behind it.
I'm also not sure I agree on your take on Sprints. In my mind, the value of sprints is that they provide a barrier where you should be able to go "we already loaded all our work for the next 2 weeks. If you want something done, we'll start it in N days." Done right, sprints are your defense against "can't we just do this thing".
re: sprints: You don't need a barrier against "can you do this thing". If the thing is important enough, do it; if it isn't, don't. You work on whatever the top priority is, and your sprint commitment is just a list of what the priorities were, N days ago.
(Edit: you do still need a PO willing to say "doing the thing would delay the other thing" though)
What about review? Code review? QA? Showing off to stakeholders? These things add a delay, and there is a 'crunch' around the end of sprints where things are artificially urgent. I am not sure that is optimal. I have not heard a reasonable solution to this, other than abandon sprints maybe?
I think this stuff works wonders when at MVP stage and number of users < 10 maybe. For mature and complex products, the type I typically have worked on it is not ideal.
Also a 'crunch' around the end of a sprint sounds like mini-waterfalls.
How I have seen sprints done is you commit to X Y Z, have a definition of done like “is in production” and then developer works on X, gets X code reviewed and so on.
If the aim is that the right amount of work is in each sprint then naturally the last day will be busy trying to get stuff reviewed.
I guess you can then get rid of the 2 weeks? Because you can measure velocity as a continuous rolling average. Retros could be continuous too and standups already are. Grooming is easy to make continuous too.
I’ve been part of teams working this way without sprints and artificial crunch on mature and large scale services, so it really isn’t a MVP/startup only deal…
Take a look at Dave Farley's Continuous Delivery YouTube channel to see the answers.
I think it boils down to "don't do that" with good arguments why and how to assure quality instead.
Absolutely.
> 2. Sprints aren't a failure of agile, they're a failure of devops.
I don't think so, here's the timeline: Scrum (90s), Agile (2001), DevOps (2009). So sprints have been around a long time before DevOps, the way I interpret it.
> 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular than months
How? Your event horizon spans only the next couple of iterations, everything beyond that is pure speculation.
> The problem is that Scrum started out as a lightweight wrapper around Extreme Programming (XP) to make it palatable to management, and it is all that extra cruft that people of added that is the problem.
Look at that statement, and then let’s abstract it and make it a bit more “polymorphic.”
The problem is that process ______ started out as a wrapper around idea/adhoc practice _______ to make it include management, and it is all the other crap that is added that is the problem.
Every time management gets involved with the teams I work on, this is what happens. I hear tales of people who have “helpful” management. Some of my managers have been the nicest guys, and tried to do well by me. But because they’re not part of the team, they rarely add value, but rather burden the team with their non value adding presence.
(Kinda ranty, I know, I’m just channeling the OP which was titled a rant, I guess)
This pretty neatly summarizes my ~25 years of experience in the industry! With the additional observation that most developers and managers are not aware of this phenomenon... :(
1. On a project, my team worked hard not to miss any deadlines. it worked, but the project was delayed for other reasons, and the PO told his superiors that the project was delayed because of the development team anyway.
2. On another project, my team didn't need to estimate or have a deadline. BUT at every meeting the boss said the project was behind schedule. WE WERE LATE EVEN WITHOUT A DEADLINE. Total nonsense.
If your boss is crazy, your job has a lot of politics, etc, nothing will work, and this kind of environment loves to embrace Agile methods.
I second that sentiment.
I've worked in places small and autonomous enough that the office manager would handle the admin of posting a job ad, passing on the CVs to the person who knew what their team was looking for in a colleague - note, a colleague, not a "new hire". The absence of an HR filtering layer left hiring decisions to those it most directly affected, but with the admin side handled by office managers (or in some cases COOs).
I've also worked in far larger places with heavyweight HR departments. Frustrating and backed by corporate policy (and as declared to shareholders) regarding recruitment processes. The question "Why can’t hiring be agile?" is worth exploring, I think.
For the majority of people, they just want to know what to do and expecting them to “become agile” is like asking them to change their beliefs related to politics, religion, etc. — AND more importantly, practice them.
If you want to become more agile, focus on improving yourself and finding others that align to what you feel is agile.
____
* Personally, to me, Boyd’s OODA model of agility is the the most adaptable. Problem is it’s not a check list and requires you to internalize is. For example, most people think being agile is always about speed, but it’s not, it’s about dynamically controlling yourself in to optimally control what is not yourself; sometimes most agile thing to do is be slow, or even do nothing — to see what happens, force someone else to act, etc. People that to me felt the most agile are the ones that enjoy being agile all the time and playing agility games.
Solving the problem may involve estimating, but blindly being asked "How long will this take?" without exploring the entire solution space, often without even being aware of what problem needs to be solved with that information, is when you get failed results. A time estimate may not even be the right tool to solve the particular problem.
If you are the one asking "How long will this take?" you have already recognized that you don't have a satisfactory solution yourself and need to defer to the experts, so why obscure useful context from those you are deferring to? While there may be some sense of pride in being the one to come up with the solution, such emotions aren't suitable for the workplace. It's okay to give someone else the 'glory' if they have the solution and you don't.
2 weeks with 9/10 fitness is a very different estimate from 2 weeks and a 6/10 fitness. The latter should result in more discussion so those you're giving the estimate to can better understand how likely you are to miss that estimate and what they can do to facilitate a better estimate. "Give me 2 days to investigate this 1 thing that's a total unknown, I can probably give you a better estimate afterwards".
The problem is very few people on either side of that table ever want to do this.
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.
I have had a lot of success using this simple formula in my 30+ years career. Both as an individual developer and when managing small to large software teams. It’s simple. It works.
It’s not hard.
Maintain a priority list.
Always work on what is #1 priority.
If #1 priority is blocked then work on #2 priority.
If, during this process, a newly discovered risk is identified as being more than what is currently being worked, put the new risk at the front of the queue and address it.
This drives risk to 0, which drives the probability of success to 1.
And as you succinctly stated:
It’s simple.
It works.If you have a clear and compelling vision, then everything else falls into place.
Start with no process and add (sparingly) as needed. Always treat process as the least important thing on any project.
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?
Money can only really be applied early by staffing up, adding more people to a late project will invariably make it later. Thanks Mythical Man Month.
So for anything in flight that looks like it will miss a desired goal you can only really change the delivery date or reduce project scope.
But you also need to know you’re going to miss so you need some idea of how much work is left and how quickly you’ll get through it. Detailed estimates are a reaction to this along with the idea of measuring ‘velocity’. I’ve never seen either work well but people seem to cling to the idea that next time it’ll help them get it right.
One of the funniest Agile meetings I’ve been in had a producer explaining the state of the project. Slide 1: Velocity doesn’t mean anything outside of the team it’s for, comparisons don’t make sense. Slide 2: A line graph plotting each teams velocity against one another. Cue any useful discussion derailed because people want to know how we can get everyone’s velocity up to what looks like the best teams.
There’s a lot of dysfunction in business and a lot of winging it without really trying to understand why things are being done. You get a lot of odd practices spread around because project success is not necessarily because of “good leadership” but often project success is the measure used for leaders. A couple of wins and you can gracefully fail upwards believing in your own bullshit.
I thought the "rule" was a single core team, not multiple sub-teams of devs.
If devs with less experience are also at the planning poking table to voice their concerns; the more experienced devs can take that feedback on board to come to a consensus estimate.
Individual tasks may be over or under depending on which dev picks it up but the idea is to get the average as close as possible to being accurate.
My own years of experience have taught me that estimates will always be sought by the customer. They may even shop around for a better price with a different software vendor/low code solution etc.
If the development team doesn't know the estimate, how is management expected to know? Simply put, management will be held to whatever number (of person hours) they provide, and are also expected to keep it low enough to close the deal. Deadlines are part of doing business, no matter how much we try to dance around that fact. This is why management will immediately turn around and convert story points into hours. These guesstimates will then become deadlines. I hate having deadlines for creative work, and would rather not be bothered by them, but they exist nonetheless.
Until you convince your customers to accept "NFC" and still do business with you, Agile will remain a quixotic idea for the corporate world
Can we please not fool the next generation of software developers into believing all this bs?
Unless there is a constructive dialogue between the people who build it and the people that want it, it will end disastrously. Just think of all the failed white elephant projects that get “negotiated” on the golf course.
Until there’s an acceptance that being agile isn’t just something developers do but has to be adopted by the whole org, it’s not going to work. I know it sounds a bit dreamy but I’ve worked in big orgs that did agile rather well, so it is possible…
It depends on many things, but from my experience, it’s possible, we went from 40% to 10% margin of error per quarter. When there’s a will, there’s a way.
Agile is what managers who have no clue about the agile manifesto do after they attended a mandatory, 6 hours long SAFe training. "Doing Agile helps the coding monkeys output three times as much as before? Gotcha!" When you prescribe the same sprint start day across the entire organization, that is Agile. If you have 6 weeks sprint commitment, that's Agile. When all teams need to estimate stories using Fibonacci, that's Agile. When the dev team needs to commit how much time they need for a feature that is planned for next year Q4, that's Agile. When the company needs an certified coach, that is Agile. When I need to create a Jira ticket and got it approved by three people to change the name of a small class, that's Agile.
I use "agile", when a company or product team understands that when writing software, you need to adapt to the things you find out. You don't know what you will do in 27 weeks and there is no point in story point estimating that stuff a half a year in advance. The company is agile when one team can use Scrum, another team can do Kanban, yet another can do whatever they come up with that works for them.
I agree it's helpful that there's a common theme on how "we" do things, but the point about making it organic is spot on. Nobody does things so they do scrum. The goal is to deliver something useful, how that gets done might be very different in different contexts. So mold it to how you do things.
My own view is that estimates are useful, but should be treated less as a fixed point-estimate prediction, and more as a single step in a kalman filter, with the understanding that the output at each step is probabilistic, and the number of steps is unknown.
However, the "don't estimate" school is just a little crazy. In no other discipline would this be acceptable as a doctrine.
Imagine a contractor you hire to build the house shrugging when you ask him how long or how much it will cost.
I've been on teams where estimation is easy - you've got years of roughly the same set of devs doing fairly similar feature/bug work on the same code base to look back on and give an educated guess on sizing. Right now I'm on a team that's mostly doing integrations with third-party systems where our skill levels on the team vary between 20 years and 6 months of experience in the field, let alone this team.
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.
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 of unknowns, new concepts, many moving parts, unsolved problems, to build a new invention.
Of course they do: people, furniture, water, air, heat.
If programming indeed was "usually" like that, then there shouldn't be much software getting produced at all. Since building "a new type of interdimensional alien spacecraft engine" is something that's very very unusual, to say the least. :)
The problem is I see estimates like this;
$COMPLEX_REQUIREMENT: 12 days BACK END - 3 days FRONT END - 3 days UNIT TEST - 2 days
...
Which is almost certainly gonna be wrong, so it useless. But "12" is a number and number can be added.
We have 274 man days this quarter, and of course we allow time for bugs and leave and stuff, so sum of estimates is 263, so that's our plan for the next 3 months.
Never works.
Estimates are useful for making branch decisions though.
So knowing is it 1 hour or 1 day or 1 week or 1 month or 1 year (which is closest) is useful for deciding if it is done (hint if it involves code at all then not 1 hour!)
For each category, accept it might take up to 5 times as long. So 1 day = 1 to 5 days. 1 week = 1 to 5 weeks and so on.
Is it a disaster if the thing took 5 weeks?
Id there another "1 week" tasks that is more urgent than the one you are thinking of doing next?
That is the level.
Then don't track too closely how long it takes .. BUT ... maybe have a team leader flag at 2.5x estimate to discuss in depth if it is worth carrying on. In addition to standups/whatever to get unblocked or report the estimate was way off.
In a nutshell treat the estimate as a decision heuristic. But not as a developer skill measurement tool, or a timeline delivery.
If you have a real deadline, then presumably you agreed to it (some contract) and hopefully when coming to that agreement technical people were consulted, and loads and loads of buffer was included. It is like agreeing to host people on Christmas day - it will probably need say 20 hours of prep, but arranging it 3 months ahead of time and slowly working on it the whole time is a surefire way of success. Starting the project on 23rd Dec is a surefire way to fail. Common sense in real life (because we use common sense not trying to "optimise" every last second).
Also in real life if other things mean you can't host Christmas ... you don't agree to the deadline. Let's book a table at the pub. That is what you do. Companies tend not to do that, they agree to all kinds of silly things. And you get silly deadlines, and bullshit estimates as a result.
Standards, structures and processes are still something I wouldn’t do without, but the configuration or extent can vary based on the team.
Problem I found with this journey is that Scrum concepts pollute Kanban and beyond. We now just do what works, as little process as works for us - and we implicitly review the process with each commit.
Sort of. I find real businesses with real needs who hire me as a contractor to design / develop software. They have no extra time and money for propaganda. I work either alone or hire subcontractors for help. How I actually do development is my internal business. They do not go into that area.
Agile has killed more people than Waterfall. Terrible. You should all be ashamed of yourselves. Do try harder! lol
How I know you don't know what you're talking about in 2 dozen words or less.
No amount of agileness is going to save you from a miss managed team.
Is this anecdotal or what? "I want the citations."
I don't blame you for coming to the conclusion you have, but you'd do well to signpost when you suspect something is true vs have reason and evidence that something is true.
On the contrary, Mary Poppendieck has a wonderful presentation she gave on how the Empire State Building was built in record time by literally doing it as a more agile-style construction. https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...
Likewise, American manufacturers by WWII had already gotten very good at building complicated machinery based on relatively light levels of blueprints and documentation, with the detail-level designs being added to the drawings used on the factory floor.
In many ways we have to blame the introduction of computerized project management for waterfall... it simply wouldn't have been workable before that to even attempt a real waterfall method for projects.
> Kanban is a core but small part of TPS, it can't be said to be pro or against safety.
The poster's point is that it's not obviously defective from that standpoint, despite criticisms that imply that it is.
This process includes multiple reviews in a "SETR" (System Engineering Technical Review) process (https://www.acqnotes.com/Attachments/SETR%20Navy%E2%80%99s%2...), including steps like:
* SRR (System Requirements Review)
* CDR (Critical Design Review)
* TRR (Test Readiness Review)
Example of slide 15:
Example of Items from SRR Template
* SW Development Team
* Integrated Mater Schedule Highlighted with Software Milestones
* Software Entrance Criteria
* Requirements Analysis and Allocation Methodology (sounds agile to me!)
* System Specifications Tree
* Contract Data Requirements List (CDRL)
* Software Development Strategy
* Software Development Process
* SW Safety, Information Assurance and Security requirements
* Software Supplier Management
* Software Measurement
* Software Risk Assessment with Mitigation Strategies
* Issues and Concerns
Never had my soul be destroyed as completely and I seen such a massive waste of time and money.
The Royce paper saw the one-shot waterfall as unrealistic even with the project alternating back and forth between phases. It ends with a complicated-looking process of writing two systems. Estimation of time to completion or cost is not really solved there.
But really what people mean when they refer back to Waterfall is the idea that you can put a reasonable upper bound on cost and time to completion of a larger project while keeping a maximum lower bound on functionality/scope.
Even in the 1980s, people were looking at business software systems and thinking they were pretty well defined in terms of complexity. A database, a bunch of data entry and data retrieval screens, some online functions, some batch functions. Maybe you could specify these like a builder specifies a concrete sidewalk. (A literal example from a software engineering book). Then estimation should be possible.
The trouble is that the requirements of a multi year project are often out of date before the project is started and many specifications are underspecified until the customer has seen something like the final product. So why not plan around change? Bound the budget, allow some schedule time, and see how much functionality can be built in that time. Let the customer prioritize parts of functionality and the developers work smoothly, and the whole team can stay in a mode of delivering functionality frequently.
Royce 1970. https://dl.acm.org/doi/pdf/10.5555/41765.41801
Boehm 1986? https://dl.acm.org/doi/10.1145/12944.12948