I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone.
What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over.
I don't really want full waterfall again but I would really love to see some sort of lite versions of Functional specifications & design specifications come back.
Agile works best IMO in the Pre-1.0 phase of a product and gets progressively worse the further you get towards maintenance of a product. I also think Agile works better and better the closer you are to the UI, and worse and worse the further you get from the UI. Solid back end design and infrastructure rarely fits well into "Sprints" and solid back end infrastructure is not sexy at all in a demo, so Agile can demote back end design to the point everything gets done in a way that is too MVP. Then later on when scalability, performance, bugginess, and maintainability come into play you're into that "established product" phase where Agile doesn't do as well. So you've got problems in an area of the product Agile has trouble with happening in a phase of development Agile has trouble with.
Agile also seems to really require absolutely top notch product management folks, and they are seriously rare.
The thing is of the 5 shops:
* 3 Were acquired
* 1 Went IPO
* I work at the 5th currently
So the companies always had a successful exit even if the codebase passed onto the acquiring company or to the public investors had major issues.. so at least in my experience there's no feedback loop to correct the issues.
I cannot agree more with the assessment that agile works well with front end and poorly with backend.
Agile with the backend/infrastructure actively encourages taking on technical debt just to get something, anything up and running as quickly as possible. Which is great for PMs' careers but terrible for the developers who have to maintain those systems, and ultimately the organization as a whole. Maybe it's even great for job security or to get an IPO/acquisition as quickly as possible, but it really does result in much more work in the long term.
The issue is that the people who push for these terribly designed backends that suck up unnecessary human-years worth of work to maintain, patch, and fix are never held accountable. And if you're stucking as a developer working on these systems, you're screwed (and it can even be bad for your career since you're not shipping anything new). I can't tell you how much of a relief it is to just walk away from that kind of mess... which really, makes the situation even worse, since everytime that happens organizational knowledge gets lost and some poor soul gets to start working on something terrible with much less context
I think it depends. It does protect from overcomplicated designs that never come to fruition in accordance with Gall’s Law (See Googles Omega). And nobody will care how much extra debt you saved down the line if company seizes to exist because it was outpaced by competition so there’s definitely some trade offs to be made.
The last part is more of a problem with hard maintenance work being unappreciated compared to launching new shiny shit which is entirely different can of worms.
but I would really love to see some sort of lite versions of Functional specifications & design specifications come back.
None of those things are disclaimed by Agile. Agile never meant "don't do any design, requirements gathering, or specification." If the people you're working with think that "being Agile" means you can't do those things, then quit and go work somewhere else.
Remember, "there is no such thing as Agile." That is, there is no specific process or methodology named "Agile" which is prescriptive and says "don't do design". Agile is an umbrella term that encompasses a wide spectrum of different methodologies, including Scrum, XP, AUP, Crystal, DAD, SAFe, etc. Those different methodologies may argue for more or less emphasis on up-front design, but I'm not aware of any of them that disclaim it completely. If your people are saying "Agile doesn't let us do design" then they're full of shit.
The Agile experiences I've had that were more satisfying were actually the ones that were closer to "by the book" Scrum or Kanban.
The specific things that I've noticed get left out that make Agile miserable are:
- Story pointing goes away
- Velocity never gets calculated
- Retrospectives get removed
I think Agile shifts responsibility off of management and onto the engineers in even the best run team. PMs and management don't have to commit to hard decisions early in the development cycle because the methodology says that overcommitting early will lead to failure.
Velocity and Retrospectives are two of the best features for me.. Velocity is a check on managers over scheduling developers, and Retrospectives force everyone to look failures right in the eye and adapt. When you remove those two things Management can over schedule the team without even realizing it and no one has any data to show it. When you remove retrospectives no one gets to discuss bad parts of the process or bad parts of the planning.
That's just one part of being satisfied though.. if you're doing perfect agile and killing it but you're building a poor product that's not going to be terribly great either.
Most of the reality for me has actually been good products that were right for the market but ended up implemented pretty poorly due to failings that could somewhat be blamed on Agile.. it seems to be getting worse and worse over time in my experience. More technical debt, poorer scalability, more bugs, less QA (you could write a book on QA and Agile).
I did quite a bit of UI early in my career and moved towards back end over time. I was mostly all back end by the time Agile really took off. I am generally pretty depressed with the quality of the back end code under Agile. You get horrible MVP database schemas and awful quickie framework dependent code that is horribly inefficient and really hard to remove later.. but that path is super quick for that MVP "gotta demo" mentality. I think this stuff really kills the morale of back end developers and leads tons of people to move on.
>So the companies always had a successful exit even if the codebase passed onto the acquiring company or to the public investors had major issues.. so at least in my experience there's no feedback loop to correct the issues.
In a sense, it sounds like there is nothing to correct! Would moving more slowly and deliberately have improved the exit, or worsened it? Perhaps code quality has only a tenuous link to business outcomes.
I periodically think about this line I found on the C2 wiki:
"I believe it is time to explicitly state the long held secret of software, we do not need to do design; design is ineffective and costly." --Wayne Mack
It's really hard to argue with a money printing machine. That theoretically it might print faster or at least longer for a bigger integral, after doing things that seem to slow down printing now, is also hard to believe if the person you're arguing with has never experienced such a non-linear outcome.
That sounds like a line by someone who has never seen the disaster that some incompetent people can do. Design is not necessarily something done by a kind of mythical "architect" (whatever that means...); instead, a good programmer simply very often write software that has a good design.
And I would say than in most areas, design is effective and required.
NT works. 9x is long-dead (and even 9x had tons of design, but there was just a gap too immense on some fundamentals to get anywhere)
I would even make the hypothesis that good design is always eventually effective and required, but the period of time after which lack of proper design hits you badly varies, and in some fields it is actually longer than the lifetime of the product...
I've come to expect that code quality has a strong link to success but in sometimes its inversely proportional. What I mean, is that at the Seed/Series A timeframe, I doubt you will see a strong performing company, with a codebase with high quality. I also the odds are against seeing a tech company with billions in revenue (not worth) have a really poor codebase. I can think of plenty of examples where the desire to 'do it right', has cost a company their marketshare.
As much as Netscape vs Microsoft hurt Netscape, the time it took to do NS7 and the quality it shipped with, pushed them back 5-6 years.
One thing I learned a long time was this: A "bad" process that has complete buy-in and everyone participates in will always outperform a "good" process that has lip service buy-in and disagreements about who does what.
A team that has skilled individuals exercising judgement and thinking critically about tools (for project management as for everything else) will alway outperform one that’s subordinate to a process.
Absolutely. I let the pms do their thing and follow the rules. Every organization I've worked with is thrilled when developers get buy in, but guess what your process is still pretty crappy and we just want to make you feel good about it.
Positive criticism always falls on deaf ears - "why not just give it a chance" blah blah.
Our agile process has complete buy in from developers.
Yet the product is markedly inferior to the same product we created with fewer developers in a shorter period of time, while also creating the backend services, right before we created this product, when we were not following ‘agile’.
Because the current management approved Agile is just a bunch of rules that are enforced upon us. The previous process was basically an ad god process we had built up using best practices, adapted based on our own experiences with the unique needs of our team. In a sense, we were far more agile when we were not doing Agile.
I'm ready for what comes next after Agile.
I've been through about 5 Agile shops now. I would say
one of the 5 ran Agile well, the rest were a mess that
just makes it frustrating for everyone.
I can't tell you what will come after agile, but I can tell you that it'll probably have around a 20% effective rate all the same.
Also there's nothing in agile that would prevent you from designing things upfront, I believe the exact phrasing is "Responding to Change Over Following a Plan". I.e., build extendable / adaptable designs (that can change), do the amount of specification upfront that provides value, but don't ticket-plan 2 years of development upfront.
I'd also add: much of the culture and thinking surrounding Agile grew out of software consultancies: organizations that have the privilege of green-fielding new projects and then "abandoning" them; either because their contract was over, or there's no desire (or capital) from stakeholders to improve the software. So it doesn’t surprise me that their model breaks down for software that undergoes continuous modification for years, as that’s an atypical case for consultancies.
The outcome can only be as good as the sum of its part. The best methodology with the worst people will still result in a poor outcome. The best people with the worst methodology might still manage do deliver something useful. The best outcomes come from trusting good people do what they're good at. Why trust a manager over an engineer?
Scrum != agile. You don't need sprints to be agile. If sprints aren't working for you and your team, then stop doing sprints. If your team can't decide to stop doing sprints, then you're not leading your own agile process and you're not really doing agile.
Let me clarify that -- there are people who are using Scrum to do agile. Scrum is not _against_ agile. But if you are doing two-week sprints because management is chasing the latest fad, without empowering the team, you're not agile, you're just in a Scrum cargo cult.
Exactly this, agile is all about empowering devs, trusting them and allowing them to work.
Sprints are about enforcing feedback from the customer into the loop. If you have a half decent customer they should be happy with any length sprint and releases that make sense.
No, sprints are about creating artificial deadlines to stress developers to work more hours to meet so-called commitments/forecasts.
It does not work of course, but that is what it is about.
Well, there's supposed to be -- Technical Quality - Refactoring.
Common to all flavours of Agile (I lecture agile techniques) sounds like you guys are missing out important parts of agile... but I totally agree with what you are saying. I'm old Skool and grew up with waterfall. I find it really weird teaching students who don't have a spec or UML diagrams or any idea what a software pattern is. Hell, some of them don't bother with a Model layer - not enough time to implement it in a sprint, so why bother? Lol. They get code out the door, but quality code? A-hem, it is possible, but do people do it?
Of the agile shops I've done similarly only one did it well, and I won't lie - there was way more process and documentation than any waterfall shop I was ever a part of.
Dave Thomas, one of the original authors of the Agile Manifesto [1] wrote an article called "Time to Kill Agile" [2] a few years ago (which he subsequently re-titled "Agile is Dead"). He has some good insight on how Agile (the methodology) got to be something very different from what they intended. Originally they were trying to break away from a rigid methodology, not introduce a whole new one. Unfortunately, if you don't codify something into a set of rules, it's pretty hard to get people to follow it, and it wasn't long before "experts" were building formal processes out of it. I've never seen it work well, and the more ardent the adherents are, the worse it seems to get. I think every team needs to find the approach that works best for them to itemize, prioritize and communicate progress. In my experience the two most important aspects of moving a project along are simply communicating what needs to be done and recognizing effort.
> I think every team needs to find the approach that works best for them to itemize, prioritize and communicate progress.
This is spot on.
And the fact is, this has been known since at least 1980's (!)[0]. I am quite fond of using the version "culture trumps process", because it so well encapsulates the reality. (Also: hits directly against "The Process" ideology.)
It often feels like everyone and their dog within the industry are hell-bent on establishing a Good Development Process. But that's a false premise. You can't just introduce a designed process and expect it to magically fix things. Workflow is everything: motivated and talented people will go to lengths to get their actual work done, process be damned. The best thing you can do is to invest in good tooling and actively encourage sane development practices.
Get the workflow right, and process will follow. Crucially, as you said above, every company will need to find their own flavour.
> I think every team needs to find the approach that works best for them to itemize, prioritize and communicate progress.
Couldn't agree more. A development process is like your CI pipeline, there's no one solution for everyone, but there are common patterns you can choose from and build upon to make something that works for you. And it's something that you will want to assess and refine on a pretty constant basis.
I've worked on everything from high-integrity embedded systems to web applications over the years, and what worked for one would be catastrophic (both metaphorically and literally) for the other.
I've dealt with "agile experts" who appear to never have actually read the agile manifesto. For those "experts" is always about following the rules and process of their version of agile.
What gets presented by these "experts" is rarely anything like the original indent if not the anthesis.
"What do you think is the most important principle in the agile manifesto?" is one of my favorite interview questions. I'm yet to interview for a position as "agile developer" and have the interviewer know what the manifesto is.
It's more like a brand vs an idea. The word "Agile" was used (like that, capitalized) mostly as a way to designate adherence to a procedural cult (e.g. the Scrum cult) and usage of specific words looking like newspeak (Sprint, Stories, Epics).
The concept of agility, with the word taken as in its common word meaning, does not actually need all that bullshit. Well, neither does the general concept of being agile in the first place, but it is harder to distinguish from the now tainted one "Agile".
I think there's a fundamental misunderstanding of agile. Agile isn't Scrum, agile isn't Kanban, Agile isn't even really the manifesto. Agile is, like lean manufacturing (one of its inspirations), based around one really simple concept: the workers know the most about what they are doing and should be leading the charge on what they are doing.
If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. If agile is just another way for management to exert control over software development, rather than being about ceding control to software developers, it won't "work."
This is the same thing you see with lean/TPS, by the way. The joint GM/Toyota venture showed that without committing to these principles, adopting parts of TPS don't really deliver the full benefits.[1] As one UAW team leader said about why working for Toyota was preferable to GM:
> The GM system relied on authority. People with rank, the managers, ruled regardless of their competence or the validity of what they were saying. It was basically a military hierarchy. At NUMMI rank doesn't mean a damn thing. Standardized work means we all work the objectively best way to do the job, and everyone does it that way. I might make some minor adjustments because of my height, for example, but I follow the procedure as laid out because it makes sense. We're more like a special forces unit than the regular military hierarchy. Management's delegated responsibility to the people who do the work, and that gives workers a sense of pride in their jobs.
If management is asking the developers to adopt agile, but they aren't doing anything to adopt agile themselves, good luck.
Similar musings under the "Dark Scrum" heading by Ron Jeffries:
> Every day, the team is supposed to get together and organize the day’s work. [... The ScrumMaster ...] knows his job. His job is to stay on top of what everyone is doing, make sure they’re doing the right things, and redirect them if they’re not. How convenient that there’s a mandatory meeting where he can do that, every single day!
> In practice the Dark Sprint Review begins by someone reminding everyone what the team “promised” to do. (That is, what was demanded right before the team said “We’ll try”. That’s a promise, isn’t it?) Then we look at the pitiful failure the team brings us.
If I keep up my training regimen, within two years I’ll be able to leap across the conference table and backhand the guy using the word “commitment” before he gets the last syllable out.
> If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. If agile is just another way for management to exert control over software development, rather than being about ceding control to software developers, it won't "work."
This is exactly what it has become though. It's not about developers, it's about managers and product owners. It's about numbers in a spreadsheet that managers can show upper managers.
Management has sucked the life out of agile. It's become this rigid metric producing muck that gets in the way.
Bad management is Nosferatu: it's a blood-sucker by design. If you take Dracula out of the Carpathian Mountains and move him to Carfax Abbey, Dracula is not going to stop being a blood-sucker, he's just going to start drinking Lucy and Mina's blood.
Agile is, to my mind, more likely to get you to the right place than something like waterfall. But all the methodology in the world won't save you if management is bad. Putting the blame in the right place is a good place to start, though. If you're living through a bad agile process, saying "I hate bad management" puts the blame in a more correct place than "I hate agile."
Agile was a reaction against particular problems in management, the Agile manifesto is directed at them on a conceptual level, but the Agile body of work (unlike Lean) has largely avoided solutions to the problem Agile is a reaction against and largely consists of solutions to lower-level problems that take for granted that the high level problem is already solved.
Which is why it seems to “work well” in young organizations with relatively small, hands-on engineering-heavy teams without several layers of non-technical (in practice, regardless of past experience) management—those aren't the places where the problems tend to exist in the first place.
Sometime I equate the near constant complaint about Agile processes with a hypothetical set of engineers complaining about a 'baseball' process. "The 'Baseball process' sucks because our psychopathic managers beat us with the bats to get us to work harder. If only we switched to the "soccer" process, things would get better because there's nothing for them to hit us with, they'll just punch and kick us. "
> Agile is, like lean manufacturing (one of its inspirations), based around one really simple concept: the workers know the most about what they are doing and should be leading the charge on what they are doing.
The difference between the Agile literature and the Lean literature (including Lean Software Development, which has its own body of literature separate from Agile) is that almost nothing labeled “Agile” actually addresses that central value (except the Manifesto, which does so at a conceptual but not actionable level). It all just skips to concrete decontextualized practices of exactly the sort that the Manifesto’s “people and interactions over processes and tools” is a reaction against, while the Lean body of work actually addresses (without narrow prescriptivism) higher level meta-processes and practices which empower workers to drive the process of evaluatibg and adapt the low-level work processes to acheive business value.
Agile is basically the values of Lean accidentally recast in less-concrete way which empowers the kind of management consultant snake-oil solution vendors that it was a reaction against. While there are some decent ideas about low-level practices that are worth considering once you have the appropriate Lean organizational culture in place under the Agile banner, the body of work under that banner is mostly a distraction from the goals it notionally serves; better to ignore it all and focus on Lean than to make it front and center.
> If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments.
Story points being used for the team and to tell management how much work is being done are not mutually exclusive. I'm also not sure of your distinction between "on-task" and "commitments". If I've made a commitment, there are some tasks that need to be performed to meet that commitment, no?
> Story points being used for the team and to tell management how much work is being done are not mutually exclusive.
That's the thing though, in reality they really are mutually exclusive. As soon as management starts using a metric to measure the team's performance, that metric stops being useful for the team to improve itself, because now there is a perverse incentive to inflate the metric to get performance rewards.
Yes. Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure." As soon as management starts looking at story points, it's a scramble to get the most points possible in a sprint (or at least, to not let velocity go down).
I had a VP, new to my company, come to me and say, 'Your velocity is pathetic, at my last company my engineers were doing 14-16 points a sprint, yours are only doing 8-10'. I tried to explain how that wasn't a thing and we could just start doubling our points. He seemed to indicate that's what I should do ... I started looking.
In a daily standup, it should be about commitments _to your teammates_, not to management. In other words, Bob needs to do X before Alice can do Y, so Bob commits to Alice about his work on X. If there's problems, they can talk about it. That's not the same as some middle manager coming in and going, you need to do X to hit some KPI.
Just today I read a quote on Lean. It was Substance of lean vs. form of lean. And that only a minority is actually having the substance. Guess that applies to Agile as well.
This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy.
Agile is basically implemented to create an iterative feedback loop in the development process, but it seems totally rational that what works for startups won't work for very large distributed companies, and what works for an app developer won't work for an automotive supplier.
Standups can take different shapes, the 'V' in MVP differs wildly by industries, and the cycle time that a product needs to have can be determined by external market forces (e.g. the school year).
Agile is meant to adapt to the characteristics of the business it is used in, rather than to be specifically some universal way of everyone trying to everything in the same way.
> This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy.
Maybe so, but you are also describing Agile as if it can be anything a company wants it to be, which effectively makes Agile meaningless.
I've worked with clients that have a waterfall-like development process, "standups" that are both status-reporting to management and on the spot planning, adaption to change is very slow and cumbersome, velocity charts serving management more than the team itself, tickets that represent multiple stories at once, management adding tickets(i.e. more story points) without removing less important ones, gigantic release cycles, etc.
For me the "minimal set" of rules that can still be called Agile is a mechanism for measurement, and a retrospective. You use the retrospective to perturb the process, and you use the measurement to decide whether that perturbation was a success or a failure.
That's it - old school cybernetics. If you used feedback loops to iterate towards a successful process, you're doing Agile. If there are parts of the process that are off-limits to you (eg management insists on doorstepping your standups) then you're not doing Agile.
Of course, we "prime the pump" somewhat by throwing in a bunch of extra rules at the beginning that we know from experience are likely to work, but I think that Agile, done right, has a lot in common with Nomic.
Of course not, and that's really the point. Plenty of organizations will tell you they are Agile when they aren't truly following the Agile manifesto, but that's not going to stop the evangelicals from eating the horse manure("our team has standups 'n stuff") that reassures them that their belief system works.
Everyone's bullshitting each other, and I wish it would stop, but I know it won't. Not everyone can be a "true scotsman".
I'm not even defending Agile or other related methodologies like Scrum. They have some good ideas, but I haven't seen quantifiable evidence that they are good for businesses. Many of the ideas are good for software engineers, but that doesn't mean they are actually good for teams or companies. Even then, I've management use "responding to change over following a plan" as a license to make more arbitrary changes to what engineers will work on in a given day because they can take it. Planning days and point systems be damned.
Does any one have good (as in: known to actually have had a positive effect in the past) insights on how to convince your manager(s) that (at least their version of) "agile" is not helping the company?
My wife works in a company where the managements seems to be quite "proud" to apply "agile methods" but in my wife's opinion, it's more BS bingo than producing a measurable boost in productivity, quality, or any other desirable metric. It is her impression that they are forced to adhere to certain routines even when the benefit is questionable. For instance, every morning at 9pm the whole department has a "daily scrum meeting", but most of the time there's nothing important to report from the day before for a lot of people, so it tends to lead to either embarrassment, pressure, or to people making crap up just so they have something to say. Needless to say that this doesn't lead to "team building".
That's just one example.
So, either the specific way "agile" is executed in my wife's company is just stupid, or the whole methodology is perhaps not applicable to their setup -- or something else. But it seems that the current practice is just a gigantic waste of time, yet the management is so proud of their "agile" way.
I know what you describe is common, but the purpose of the daily really isn’t to boast about your heroic achievements of yesterday, or give a status report to management. That part should be cut out entirely much of the time.
A better idea is to plan the current day, identify where someone could use help, where two people need to coordinate more closely or on what issues further discussion is needed and with whom. If there’s nothing to discuss because everyone is already on the same page, that’s great, cut the meeting short and start working.
Also, depending on your setup, people who can never usefully work together on anything probably shouldn’t be part of the same daily standup. I’ve seen several cases where this meeting was way, way too large.
To put a finer point on it, a daily stand-up meeting should be no more than 15 minutes long, and about three specific things. Each person should talk about exactly these three things (or less, if you can say that one or more of them are not known or relevant yet):
1. What am I working on now
2. What is in the way of getting this thing done
3. What will I work on next
The value of the stand-up comes from the replies you can get from your other team members when they hear your report...
(1) "I know something that you need to know in order to get that done well, or done at all" ...
(2) "I can help with that thing you've identified which is in your way" ...
(3) "Here's something you will need, let's get it ready for you..." or alternatively "That's not going to go well because XYZ isn't ready yet, so maybe plan to work on this other thing instead"
If these things aren't coming out of your daily stand-up meetings on a regular basis, then something about how your group is doing them is wrong.
Talking about what you did yesterday, that is already over and done with (as you say), provides absolutely no value ... unless you know from a previous stand-up that someone was actually waiting for that thing. But if you really knew that already, you should tell that person directly, as there's really no reason to save it for the stand-up unless there just wasn't another opportunity.
15 minutes? Even 5 minutes is long. With an average 7 person scrum team, they should take no more than 3 minutes.
I disagree talking about yesterday provides no value. Talking about yesterday, in my experience, dramatically improves people's ability to accurately identify and prioritize what they have to do today.
Plus, it provides a forum to communicate unexpected interruptions that may need to be dealt with by the scrum master.
5 minutes for 7 people? Something is wrong with your math, you might get the meeting over with in 5 minutes on the best day, but it won't have been very valuable or informative.
How exactly are you supposed to make three whole statements per person and also leave room for helpful reactions and questions... in an average of 14 seconds per person-statement and response?
That might be how long it takes if nobody has anything to say in response, but it won't be the average, more like the floor.
Either we're not talking about the same thing, or your dev team are moonlighting as auctioneers.
Response? The only time there is a response is if there is a blocker and even then, it is just a comment to speak after the meeting with the people affected.
14 seconds is a long time to answer them if you are prepared and don't dilly dally around. For goodness sake, the majority of time, someone is working on the same feature today as yesterday and has no blockers. It takes seconds to communicate.
It isn't like everyone isn't aware of all the work to be done and it isn't an appropriate forum in a cross-functional team to go into details. People do that after with the people interested.
The only time I've found people run over 5 minutes is if the person running the meeting is lax or if meeting doesn't start on time.
I guess sometimes another meeting happening after might get rolled in, but then it isn't a standup.
I guess we're pretty lax about it and not really following the rules. Almost always people do not respect the rules of the stand-up, and it becomes the status report meeting.
If you're doing it correctly, it should definitely not run over 15 minutes. Other groups that I've observed are having 30-minute standup meetings with 15 or 20 people and they're dominated by two or three people with lots to say.
That's not what it's for. I like your approach better than ours.
From what I've seen is that Agile doesn't ever end up working when it's driven from Management. They only care because it's supposed to be more productive, but they don't want to actually adopt any of the measures that make it more productive.
But it is always driven from management. When was the last time a group of developers decided all by themselves that they needed a development framework to get work done?
And isn't it funny how management never uses any agile framework to do their own stuff. Could you imagine the board of directors putting Fibonacci cards on their foreheads when deciding on budgets or earnings forecasts?
Guys - thanks very much for your input but note my original question. I know that what you say is right about why what they do in my wife's company is not the way things should be done. But my question was: what can be done to improve a situation like that? And not just specifically for my wife, I'm asking the more general question for others who are in similar situations.
The example I gave about the daily meetings was just that: an example, meant to illustrate why my wife thinks that it seems more important for their managers to pat their backs about using "agile methods" than to actually know what they're doing.
That said - I'd also like to point your attention to another commenter here who pointed out that the original authors of the agile manifesto were actually trying to achieve a less strictly structured work methodology. However, I get from your comments about how a daily meeting "is supposed to be done" that some of you seem to indeed have pretty strict ideas about what constitutes agile and what doesn't. So that is kind of an interesting observation in itself, I think.
Standup is one area where the engineers can affect the culture and the outcome. Expect that at the beginning of a project they can be long but as time goes on they can be quite short. Neither is good or bad, but it's important to keep things succinct. Hopefully rotate who leads the standup - even every day. Probably unpopular opinion but anyone should be able to politely ask that some subjects be handled 'offline'. Well run standups are great tools for productivity. It's not a meeting and it's not conversation. It's discovery. It's having your teammates back.
EDIT: also keep in mind different personalities. Some people just aren't socially comfortable with the format. That's totally fine and hopefully team lead or standup lead will engage them directly after the standup and propagate any relevant info.
If it’s not safe to say “I got nothing done yesterday” at your standup then it’s a waste of time. Stand-ups are not about accountability, they are about discovery.
If people are talking about anything other than; what I did, what my impediments are and what am I planning to do then they are wasting time. Book an actual meeting after the standup to discuss things.
If there are too many people to remember to book meetings after the stand up, your stand up is too large.
It can take < 60 seconds for each person in a stand up to cover the 3 questions. If people take longer they should be more concise and focus on only the important things. We probably don’t need the nitty details. It’s ok to practice this.
They don't follow the "what you did yesterday, what you plan on doing today, is there anything blocking you" pattern?
And the whole department is on one scrum team?
No one should lack for something to say or have to make anything up. It is a simple status synchronization with your team. The only pressure anyone should be under is remembering what they did the day before and prioritizing what to do today.
No and yes for your two questions respectively (although I'm not 100% sure about the "no" to the first question).
That's what I meant when I said that their interpretation of agile seems really pointless. It seems like it's more important to have the "agile" label stuck to themselves than whether whatever they think that labels stands for brings about any positive effects.
I found myself in the same situation multiple times. There were times, when I was just trying to convince people we should do things differently and wasting less time. It was never working.
The article presents too many Agile/Scrum "artifacts" for my taste, eg
Agile favors so-called T-shaped skills
Adam Smith would be turning in his grave
Agile is a true democracy
LOL
The Agile philosophy certainly has something to say, but it's not hard to see the possible negative implications of "self-managing/self-policing teams" when they're owned by capitalist organizations.
These kinds of ninja teams can be extremely effective, but they should own a share in what they create, otherwise the whole thing becomes a BS attempt to make people work harder via "transparency"
i feel very much this gets close to the issue. (for me at least)
if agile is supposed to empower the team to self-improve and self-organize, then being placed into a top-down hierarchy where the upper levels are always in charge anyways is a contradiction in itself and is a huge cause of disappointment that it’s “not working”...
well of course it’s not working if i it’s being imposed by “the top” and for their own reasons... right from the start it’s not team-centered, so there you go.
A common point of contention is that agile is a list of philosophical guidelines, not a hard-and-fast framework for how to do things. A "true agile" shop should be periodically reviewing and updating their processes in the light of what makes the most sense. If, however, "being agile" is an organizational checkbox then some form of generally accepted agile methodology will be implemented whether it is the best fit for the company, whether the teams truly understand it, and without a built-in plan to reflect and decide if they are even doing agile right or if it's actually benefiting the organization.
> Middle managers can also miss the importance of co-locating teams by bringing together designers, engineers, product managers and content specialists in the same physical space. The most highly functioning agile teams aren’t just at the same location or on the same floor: they share the same table.
I can't refute this strongly enough. Managers should do their jobs and manage. Doesn't matter where team members are located.
Anyway, this agile nonsense gets too much air time. We got it: highly iterative feedback loop development.
I couldn't agree with you more. At $CURRENT_PLACE we preach an iterative spiral that I believe is appropriate for the sort of embedded safety tech we work on that has built in time delays for testing at (for ex) UL or whatever NRTL is the NRTL of the day. Whether we're succeeding at differentiating it from serial waterfall is debatable. I think we are because marketing travels to see us every other week and they're meaningful yet we avoid what seem to me like make work bits of agile and scrum. Absent the imposed processes everyone works closely enough together that we can finish each others sentences most of the time and most of us appear look forward to coming into a workplace where the manager is absent half the time but because his most important role is to his bosses from interfering with us and to clear out the obstacles in our way it works pretty well.
I don't think I've been in a truly Agile shop, though a few times we had truly Agile periods on a given project.
That said, some worked. If they:
* considered every task to be a mix of features, deadlines, and resources, and realized that if you fall behind, even a little, you have to adjust at least one of those three
* iteratively completed tasks and reviewed any adjustments to the overall project
* Had dev <=> management be two way communication
Then things were pretty smooth, even if they weren't Agile.
My current experience with a distorted Agile approach is that it is used as an excuse to not have a big design. The idea is to not block on a big design UP FRONT. Not have no design at all. So the platform I'm working on now has been torn down to the foundations and fundamentally rebuilt at least twice because the lead(s) on the project never looked further than one sprint out. Somehow it is expected that an organic design will spring from nothing. Very unfortunate.
I work at a large national software company who shall remain nameless. At some point, they determined that "we are now Agile" and put all work in a tracking software, and everything must now be assigned to sprints.
But if you dig any amount of depth down it becomes ridiculous. An example I found, the helpdesk literally has one project every sprint ("Ticket resolution: February Sprint 1", "Ticket resolution: February Sprint 2", etc.)
Or tasks that used to take 2 or 3 days now gets split across 2 or 3 sprints, because guy 1 can't allocate it to guy 2 until he finishes it. And it just sits around until the next sprint.
Even creative departments are supposed to snap-to. The idea is a recording a video should be a dozen or so tickets in Jira (edits and revisions happen as bugs). These teams are smart and overworked enough to completely ignore the directive.
And the amount of PMs has increased by an order of magnitude, because taking things in and out of the tracker has become its own workload because managers want to see more and more detailed 'analytics', so work get broken down into finer and finer pieces.
I describe the situation as if someone tried to make their truck lighter and faster by bolting a Lotus onto it.
> Or tasks that used to take 2 or 3 days now gets split across 2 or 3 sprints, because guy 1 can't allocate it to guy 2 until he finishes it. And it just sits around until the next sprint.
This so much. Because no PMs want to adhere to "sprint forecast," but insist on "sprint commitments," you literally cannot commit to doing a unit of work that depends on someone else getting theirs done first until they are done. A smooth flow that gets to market quicker now _must_ be lock step gated by sprint start dates. /me sighs
It’s notable that the ratio of “that’s not really agile” to “this _is_ agile” comments in discussions like this is typically about 10:1. Everyone knows what agile isn’t but no one can seem to explain exactly what it _is_.
Furthermore, the “you’re holding it wrong” criticism of everyone who gets poor results from agile, which seems to be a majority of people attempting to use agile practices according to articles like this and comments ITT, is a major cop out. If 75% of people attempting to use a tool hurt themselves with it, you should start asking whether this was a well designed tool in the first place.
My solution: stop using the term “agile.” It’s so vague and means so many things to different people that it effectively means nothing. Instead, talk about specific practices (sprints, story points, etc) and be able to explain the purpose of each practice. This can clear away the agile fog and get people discussing actual trade offs rather than agile magic dust.
There is no one “Agile Methodology”. It’s meant to be a communication protocol you grow within your organisation based on the principals outlined in the manifesto.
The title of the article “Everyone claims they are following “agile methods” but few actually do” suggests that there is something called “agile methods” that can be followed. I don’t think I understand what you mean about it being a communication protocol. In any event, it seems beyond debate that the term “agile” is extremely widely misunderstood. I’m arguing that instead of tilting at windmills trying to correct everyone who is “understanding it wrong”, we give up, discard the term, and focus the pros and cons of specific, describable practices. Agile seems to be more of a feeling than a practice.
There are some codified system of rules and behaviors that people have developed to help their orgs gain agility e.g. Scrum, SAFe, etc. But there are probably an infinite ways to skin that cat. Doesn’t really matter which one you use just that everyone is using the same one.
Which leads me onto why it’s a communication protocol. Human systems/processes/procedures just organise the flow of information, often to help people make decisions. If everyone isn’t following the same set of rules and behaviours then there can be a breakdown in communication. Which usually screws things up (whether top down or bottom up)
IMO the problem is that people want to buy Agile. They want to pay a consultant, or go to a class, implement a dozen scrum rituals, and call it “agile.”
Agile is not Scrum, Kanban, or even XP. It is the manifesto. It is shipping all the time at a sustainable development pace.
I have had great success implementing agile and I attribute this to continually reindexing on the manifesto and examining the impact of our process. Spoiler: removing processes is a solution as often as it is adding a process. No amount of stand-ups or sprint planning or retrospectives makes your software process a good one.
I would recommend for the author of this article to read the original Agile manifesto and point out where the so called Agile methods and resourcing models are described.
I am often only resourced 10% to some Agile projects, because my expertise is often only required for a small part of the project. And yes a copy writer can do my job as well, but would you really let an average electrician build the timber structure of your roof while the plumber wires your house ?
Most people who have an opinion about Agile don't understand it, and nobody understands it because the industry doesn't make it mandatory. It's the same with DevOps... A great idea reduced to a buzzword due to confusion.
I was a late comer to software development so my career is relatively short at this point. I have worked for 2 different shops and had wildly different experiences with agile.
The first is a fortune 500 company that is not a techy company. They have a lot crusty old infrastructure and when they decided to do agile, they hired a consultant company that came in and spent a lot of time training everyone in their "agile" methodology. I can say without sarcasm that it worked great. It was painful at first and it took probably a year for everyone to adapt, but I was very pleased with the end result. Agile didn't mean, don't do design. For us, Agile meant to always be designing. We set aside 2 hours every week to sit down as a team and design future features, as well as evaluate current architecture and propose changes. Outside those 2 hours, devs would do additional design as needed. We had one hour every week for a long form meeting for our BA's, product experts and development team to all get on the same page for business requirements and future product direction. In addition, the product team was available for consultation almost every day, and never fewer than 3 times a week. Our retrospectives were rigorous, and by the time I left the company, our estimates were excellent. We had gone from almost never being able to finish our sprint correctly to it being a surprise if every story wasn't finished on time. Occasionally business would throw a curveball at us and we would have to scramble to get our backlog and designs into place, but we were still able to finish almost every sprint as promised.
I'm a little over a year into the new place. It's also a Fortune 500 company, but it is know as techy and has a good reputation with the field at large. So far it has been miserable. They're one of those companies that does waterfall with standup. As a result, we have extended periods of torturous drawn out design (one guy went six months without writing a line of code for work), followed by a mad scramble to implement our designs as we realize we're running out of time. As a result, the documentation looks nice, but the code is a mess and doesn't always match the documentation. Since the team can't self organize, tech debt continues to accrue at a terrific rate. Small stories are awkward because the pipeline and commit process is too difficult and slow to justify it. Part of the problem is the lack of business analysts. Without that intermediate group to help manage business complexity, the developers are left doing an extensive amount of basic requirements gathering just to get started on a problem. In addition, there's no real institutional memory, and when business flows change, there's no one around to update old docs with the new changes. There's no real story grooming, so we routinely overshoot our sprints. Without a clear understanding of how product and development are supposed to interact, priorities are changing constantly and I've been shuffled between two projects almost at random.
I could go for hours about the two different companies but I think the difference boil down to one simple factor. The first company had a culture of continuous improvement. They had their share of failings, mostly related to not being a very techy company, but everyone in that company was deeply committed to constantly making things better. Pain points were either quarantined so as not to impede work, or they were called out and fixed. If something couldn't be fixed or quarantined, than it was tracked until everyone was so sick of talking about it, we'd find the time to fix it. The second company does not have such a culture. Everyone is very comfortable with the status quo no matter how much it slows things down. Things are starting to get a little better, but not much.
I think Agile worked well with the first company because everyone was already interested in constantly improving. Agile gave them a framework to evaluate their performance and improve it. Without that culture of constant improvement the second company just adopted the most cosmetic practices of Agile, without actually changing anything, or evaluating their own behavior.
I feel like 'agile' has become similar to capitalism or socialism in that it exists to solve a set of problems, and the internal structure of the idea does in fact solve the problems it seeks to solve, but has a whole bunch of real-world failure modes that make it tricky if not impossible to make work successfully over the long term because they're founded on assumptions of how humans work that are close but incomplete. Management always wants more granular control over projects, and agile doesn't encode a way of resisting evolution toward one of the many versions of zombie agile.
I'm working on a project right now that lacks well-specified requirements, yet we're barreling ahead with the implantation. I'm not exactly sure what's going to happen. My guess is that we'll end up with an MVP that meets the known requirements, but then we'll have to rewrite some part of it to meet the as-yet-unspecified requirements.
Companies that don't follow agile and instead, choose to pick only the subset of agile recommendations that make sense for their culture and teams, are actually the real agile companies.
It's always struck me how the attitude of agile advocates has always been so rigid to the point of being dogmatic, thereby being the exact opposite of agile.
I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone.
What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over.
I don't really want full waterfall again but I would really love to see some sort of lite versions of Functional specifications & design specifications come back.
Agile works best IMO in the Pre-1.0 phase of a product and gets progressively worse the further you get towards maintenance of a product. I also think Agile works better and better the closer you are to the UI, and worse and worse the further you get from the UI. Solid back end design and infrastructure rarely fits well into "Sprints" and solid back end infrastructure is not sexy at all in a demo, so Agile can demote back end design to the point everything gets done in a way that is too MVP. Then later on when scalability, performance, bugginess, and maintainability come into play you're into that "established product" phase where Agile doesn't do as well. So you've got problems in an area of the product Agile has trouble with happening in a phase of development Agile has trouble with.
Agile also seems to really require absolutely top notch product management folks, and they are seriously rare.
The thing is of the 5 shops:
* 3 Were acquired
* 1 Went IPO
* I work at the 5th currently
So the companies always had a successful exit even if the codebase passed onto the acquiring company or to the public investors had major issues.. so at least in my experience there's no feedback loop to correct the issues.