I’ve put together a collection of personal experiences people have had putting agile into practice. Structured pieces are great. Opinions and how tos from agile gurus are definitely helpful. But, these need to be balanced out case studies and personal stories of people in the trenches putting best practice into practice.
It’s the stories from the trenches that will really help you advance your own views on what agile means and how to apply it.
When putting together this collection of quotes, comments, images and short summaries we’ve looked for a wide variety of experiences from all different points of view about agile. The idea here is to give people a real view of how agile is being applied. We aren’t trying to put any particular point of view forward.
So, here it goes. 16 comments about applying agile in all their raw glory and in no particular order.
Ian Miell provides a deeply philosophical view of agile, channelling Sapiens
‘Coming up with useful software methodologies is not easy. The difficulty lies not in defining them, but in convincing others to follow it. Much of the history of software development revolves around this question: how does one convince engineers to believe particular stories about the effectiveness of requirements gathering, story points, burndown charts or backlog grooming? Yet when adopted, it gives organisations immense power, because it enables distributed teams to cooperate and work towards delivery. Just try to images how difficult it would have been to create Microsoft, Google, or IBM if we could only speak about specific technical challenges.’
So I’m cool with it. Lean, Agile, Waterfall, whatever, the fact is we need some kind of common ideology to co-operate in large numbers. None of them are evil, so it’s not like you’re picking racism over socialism or something. Whichever one you pick is not going to reflect the reality, but if you expect perfection you will be disappointed. And watch yourself for unspoken or unarticulated collective fictions. Your life is full of them. Like that your opinion is important. I can’t resist quoting this passage from Sapiens about our relationship with wheat:
‘The body of Homo sapiens had not evolved for [farming wheat]. It was adapted to climbing apple trees and running after gazelles, not to clearing rocks and carrying water buckets. Human spines, knees, necks and arches paid the price. Studies of ancient skeletons indicate that the transition to agriculture brought about a plethora of ailments, such as slipped discs, arthritis and hernias. Moreover, the new agricultural tasks demanded so much time that people were forced to settle permanently next to their wheat fields. This completely changed their way of life. We did not domesticate wheat. It domesticated us. The word ‘domesticate’ comes from the Latin domus, which means ‘house’. Who’s the one living in a house? Not the wheat. It’s the Sapiens.’ Maybe we’re not here to direct the code, but the code is directing us. Who’s the one compromising reason and logic to grow code? Not the code. It’s the Sapiens.
“Why do a lot of developers dislike agile?” on Hacker News:
I won’t reproduce the whole thread here, but here are a few golden comments highlighting the different ways people apply and think about agile.
KaiserPro says:
The whole point of Agile was “people not processes” However because at my company we have professional scrum masters, everything must be religiously Agile.
This means that we must have a standup, everyday. we must have a retro, we must have planning.
almost half a day a week is lost to pointless meetings. I just want to get on with my job. Trust me to use the ticketing system to figure out what I’m doing and raising blocking issues.
zzalpha in reply to KaiserPro:
This means that we must have a standup, everyday. we must have a retro, we must have planning.
Every single one of those ritutuals has value.
Just because you’re happy coding quietly, alone, in a darkened room with the door shut, doesn’t mean everyone is.
I have yet to see an agile shop that doesn’t benefit from stand-up to keep the team coordinated and on track. And retros are the forum for self-management and process refinement/iteration.
Moreover, some of those rituals (like sprint planning) are also needed by stakeholders other than the developers themselves in order to get their jobs done. Because, believe it or not, coders are not in fact the center of the universe.
almost half a day a week is lost to pointless meetings. I just want to get on with my job.
Woah, wait, wut? 90% of your time is apparently spent coding and that’s a problem for you? You know, at some point this starts to sound a lot like an excessive sense of entitlement…
eldavido says:
I’m a dev manager. We use agile, it works for us, and people are happy. All you have to do is make a giant list of all the things to do, make sure people are working enough, and on the right things, and use the appropriate level of design — sometimes a little, sometimes more.
I think the hardest thing is getting business stakeholders to get out of the “fixed project” mindset, though: here’s what we want, here’s how much money we have, how long will it take/how much will it cost? When the real question ought to be, what should we do first, given the budget that we have, that will most help the business?
Also, devs should be treated as adults. No “planning poker”, forced daily stand-ups, or any of that nonsense. Just keep your stories updated in the issue-tracking system, deliver iteratively, and keep on shipping.
So much of what gets blamed on agile feels like bad org politics/poor stakeholder management.
IanDrake says:
I think a lot of commenters here are missing the point being made in the short story. Agile is good for startups building a product where they don’t already have a known product/market fit. It’s understandable in that situation.
A client of mine uses it to unburden itself with upfront design for a 3rd gen system that is well known and could easily be built with waterfall. There have been (what I would call) two false starts already. I don’t see why agile is beneficial in this situation.
Dave Thomas gives a talk titled “Agile is Dead”
David Thomas, one of the original creators of the Agile Manifesto, gives a talk titled “Agile is Dead”. He makes a key point “Agile has been co-opted into something it was never meant to be”.
Toggl’s infographic on agile and other methodologies
From an Ask Me Anything with agile author James Shore
One commenter, Joehunk, who works on a ~5m lines of code system says:
You mentioned something that piqued my interest: “you need to be able to run your tests…” (emphasis yours). We have a big challenge defining what tests are “your” tests for any given component or feature, because a significant portion of our test suite are integration tests that cover large parts of the system.
This has been our main challenge: for such a large product, how do we balance the leverage you get out of unit testing with the need to also have confidence that the entire integrated product is in a good state? Do you have any experience with/examples of products where a dual-pronged approach had to be taken where unit tests allow developers to test individual components quickly, but system tests ensure functionality on the integrated product?
There is an interesting reply from jaybazuzi:
At first, the idea of moving from integrated tests (which are slow, brittle, and hard to diagnose) to great unit tests (which are fast, reliable, and point you to the problem right away) has some obvious limitations.
Sure, I can write a unit test for each piece in isolation, especially if I introduce mocks to separate the components during testing. The resulting tests will be faster (they execute less code), they’ll be more reliable (changing component A doesn’t have to break tests for component B), and they’ll be easier to diagnose (failing tests for X indicate a problem in X, and nowhere else).
But I won’t get the same kind of confidence that my system is correct, as I got with integrated tests. I may know that A passes A’s tests, and B passes B’s tests, but I don’t know that A & B fully agree on their contract. (To put it another way, if I test A against a mock of B, I don’t know that BMock has fidelity with B).
This sounds like a difficult testing problem. But in TDD, the answer isn’t “work harder at testing”. It’s “refactor to make the testing easy”.
Insightful comments later in the thread from aaronbjork:
I think the key is finding ways to let your teams do what they know is necessary… but still remain “connected” as an organization. It’s not about status updates and driving burndown charts. It’s about having real conversations about backlogs. Most people I see struggling with scaling agile are trying to “manage” agile teams. That’s where they’re getting it wrong. Let your teams manage themselves, and then focus your conversations with them around what’s next and why it’s important.
From cory_foy on meeting fixed dates:
There’s an adage that you can’t have fixed dates in “Agile” — but that’s a fallacy. The goal is to start with the minimal that meets their needs, and then build from there, constantly reviewing with working software.
In addition, in order to meet the date, you’ll still need close collaboration, frequent inspection, and high visibility — all traits of projects with good agility. We’ve have projects due for Super Bowl ads, as well as other serious marketing dates — and never had a problem meeting them because of the principles of agility.
Now, does something like “Scrum” fit in to what you are doing? Maybe — it depends on how you are breaking your work down. Kanban might be a better fit if you aren’t breaking things into discrete week-long chunks. But regardless of the methodology — there’s good things there worth investigating.
Agile Software Development Process: 90 Months of Evolution
Michael Dubakov, the founder of software company targetprocess, wrote an article detailing their evolution with agile. It is a detailed account of how agile evolved at their company over time.
The post is definitely worth a read but here are the key takeaways:
- They naturally shifted away from iterations to Kanban
- They replaced Product Owners with a Product Board.
- They had estimates, got rid of estimates, then bought estimates back again
- They found smaller user stories better
- They dropped TDD and pair programming over time.
How do you make sprint planning sessions less paintful?
From bongunk:
You shouldn’t be doing estimations during sprint planning sessions at all!
Estimation is one of the elements of a DEEP backlog. DEEP stands for Detailed Enough, Estimated, and Prioritised. Detail comes from the Analysts, Estimates from the whole team, and Priority from the PO.
So you should be doing your estimations during backlog refinement/grooming sessions. Where you estimate high priority (next 3 sprints) items that are detailed enough to be estimated.
Only issues that are DEEP should be brought to the sprint planning meeting by the PO. It is the PO’s responsibility to get the backlog into this DEEP state (obviously with help from analysts and the team). Sprint planning with a backlog that is not refined is an incredibly frustrating process.
One of the biggest issues I see with new teams is underestimating just how important a properly groomed backlog is. It’s absolutely critical to being successful with scrum and it needs a suitable amount of time dedicated to getting into shape.
I would spend at least 4 hours out of a 2 week sprint doing backlog grooming. I’ve found it best to split into 4 x 1 hour sessions, else it gets exhausting.
My opinion after one year of scrum experience
Taking a few pieces from Jan de Boer:
My opinion after one year or scrum experience is not positive. Scrum is almost like a religion with holy rules. Scrum to me seems noisy. Scrum here is a marketing sales argument to the upper management. Another thing I do not like is always splitting things up in the stories that fit into the sprint. Sometimes I like to work a bit longer on the subject I am into. But I cannot do it. Why? It is not scrum. And scrum is sacred.
Why Agile and especially scrum are terrible
Here is an excerpt from Michael O’Church’s post about agile:
The problem with Agile’s two-week iterations (or “sprints”) and user stories is that there is no exit strategy. There’s no “We won’t have to do this once we achieve [X]” clause. It’s designed to be there forever: the business-driven engineering and status meetings will never go away. Architecture and R&D and product development aren’t part of the programmer’s job, because those things don’t fit into atomized “user stories” or two-week sprints.
As a result, the sorts of projects that programmers want to take on, once they master the basics of the craft, are often ignored, because it’s annoying to justify them in terms of short-term business value. Technical excellence matters, but it’s painful to try to sell people on this fact if they want, badly, not to be convinced of it.
I once worked at a company where a product manager said that the difference between a senior engineer and a junior engineer was the ability to provide accurate estimates. Um, no. That’s insulting, actually. I hate estimates, because they generate politics and don’t actually make the work get done faster or better (in fact, it’s usually the opposite).
The worst thing about estimates is that they push a company in the direction of doing work that’s estimable. This causes programmers to favor the low-yield, easy stuff that the business doesn’t actually need (even if bumbling middle managers think otherwise) but that is “safe”. Anything that’s actually worth doing has a non-zero chance of failure and too many unknown unknowns for estimates to be useful. Agile’s focus on short-term business value ends up pushing people away from the kinds of work that the company actually needs, in favor of each programmer’s real-time reputation management.