Go read Jon Moore’s latest piece “The Power of Visualizing Iterative Waterfall”: “the most powerful reason to start visualizing the flow is that it shows you exactly what parts of your process you should change, and when. There’s nothing like being able to show a product manager that their availability is driving overall throughput to encourage spending more time with the team.”
Tag Archives: scrum
An introduction to Kanban
Jeff Patton put together an introduction to Kanban that has helped me become familiar with some of its concepts on his blog, AgileProductDesign.com, “Kanban Development Oversimplified”.
Some light reading (and research) on non-functional requirements in Agile/Scrum
Agile Modeling: Introduction to User Stories
Mike Cohn’s Blog: Non-functional Requirements as User Stories
aqris: Representing non-functional requirements with user stories
wikiwiki: Non Functional Requirements
Agile Coaching: Non-Functional Requirements: are user stories useful?
Artima: Johan Peeters: Dreams and Nightmares
Representing non-functional requirements is tricky. There are two kinds of non-functional requirement as mentioned in the aquis piece: independent, and distributed. When faced with a distributed non-functional requirement, adding it to your ‘definition of done‘ is called for. As you can tell by the links, there seems to be some difference in opinion in handling ‘independent’ non-functional requirements.
If you have pointers, please share in my comments. And thanks for the input in advance.
Two on project process
Aaron Held, coworker at CIM, “A House With No Front Door Keeps you off the streets”:
Scrum and Agile are desinged to solve this by making it a team effort. So in Scrum it is not the “developers” that build this Dr Seuss house, but the team. I think this is why many people fear Scrum. There is no “justifiable failure”.
CIO.com: When Agile Projects Go Bad:
Agile development also depends upon the engagement of the sponsors or customers in the process. That’s a difficult transition for some, according to Cockburn. “It looked like for a while that we were pushing all the power down to the programmers, but in fact we were evening out the power and responsibilities. Everyone gets to feel awkward about that.” In some organizations, he says, programmers ignored their bosses and built whatever they wanted.
At the other extreme, programmers expected the bosses or managers or sponsors to tell them accurately what the priorities were–not something the managers were used to. “So you get a breakdown on both sides,” says Cockburn. “The sponsors aren’t used to being asked to show up and care about the project, even [about] the requirements. … They say ‘No, that’s what we hired you to do.'” The programmers respond, ‘We don’t know; we need you to help us figure it out,'” he adds. And the sponsors say, ‘We don’t have time. Work it out yourselves.'”
Scrum – when practiced as intended, makes it hard to for CYA measures in development, planning, or management. Aaron has a point. That’s scary to some I would think.
More on Bad Agile
Steve Yegge talks about Google’s development (circa 2006) process – a process that is focused on being agile – and riffs on just how bad “Bad Agile” can be: Good Agile, Bad Agile:
Bad Agile hurts teams in several ways.
First, Bad Agile focuses on dates in the worst possible way: short cycles, quick deliverables, frequent estimates and re-estimates. The cycles can be anywhere from a month (which is probably tolerable) down to a day in the worst cases. It’s a nicely idealistic view of the world.
In the real world, every single participant on a project is, as it turns out, a human being. We have up days and down days. Some days you have so much energy you feel you could code for 18 hours straight. Some days you have a ton of energy, but you just don’t feel like focusing on coding. Some days you’re just exhausted. Everyone has a biological clock and a a biorhythm that they have very little control over, and it’s likely to be phase-shifted from the team clock, if the team clock is ticking in days or half-weeks.
Not to mention your personal clock: the events happening outside your work life that occasionally demand your attention during work hours.
None of that matters in Bad Agile. If you’re feeling up the day after a big deliverable, you’re not going to code like crazy; you’re going to pace yourself because you need to make sure you have reserve energy for the next big sprint. This impedance mismatch drives great engineers to mediocrity.
There’s also your extracurricular clock: the set of things you want to accomplish in addition to your main project: often important cleanups or other things that will ultimately improve your whole team’s productivity. Bad Agile is exceptionally bad at handling this, and usually winds up reserving large blocks of time after big milestones for everyone to catch up on their side-project time, whether they’re feeling creative or not. Bad Agile folks keep their eye on the goal, which hurts innovation. Sure, they’ll reserve time for everyone to clean up their own code base, but they’re not going to be so altruistic as to help anyone else in the company. How can you, when you’re effectively operating in a permanent day-for-day slip?
Bad Agile seems for some reason to be embraced by early risers. I think there’s some mystical relationship between the personality traits of “wakes up before dawn”, “likes static typing but not type inference”, “is organized to the point of being anal”, “likes team meetings”, and “likes Bad Agile”. I’m not quite sure what it is, but I see it a lot.
Read the whole thing.
Dealing with technical debt
codeartisan: Jon Moore: Cracking down on technical debt:
Generally, as the folks with the technical ability to recognize it, it is the development team’s responsibility to try to avoid accruing technical debt while producing product. Failing that, it is their responsibility to recognize/document existing debt and to advocate for its removal. However, note that there are often symptoms of technical debt, such as those I’ve listed above for architectural debt, that can be recognized by non-technical folks too.
On the flip side, business folks / product owners need to be able to trade off short term wins that accrue technical debt vs. taking longer to produce a product with less debt. Communication with the tech team is of vital importance here; undoubtedly there will be times when a short-term win will be important (especially with a first-to-market situation), but it needs to be accompanied by a plan to eliminate the accrued debt. i.e. Treat your technical debt like credit card debt that should be paid down ASAP, and not as a long-term mortgage.
The interest on your technical debt is probably not tax-deductible.
Very much related to my earlier post about Agile gone wrong.
“Rescuing Scrum teams keeps me in business”
Oh boy, does this sound familiar.
James Shore, consultant, lays down just how bad it gets when you ‘go Agile’ and don’t do so correctly: The Decline and Fall of Agile:
Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt. Two or three years later, I get a call–or one of my colleagues does. “Changes take too long and cost too much!” I hear. “Teach us about test-driven development, or pairing, or acceptance testing!” By that time, fixing the real problems requires paying back a lot of technical debt, and could take years.
What frustrates me the most is that this situation is entirely avoidable.
…There are a lot of teams right now failing with Agile. These teams are working in short cycles. The increased planning frequency has given them more control over their work and they’re discovering and fixing some problems. They feel good, and they really are seeing more success than they were before.
But they aren’t working in shared workspaces or emphasizing high-bandwidth communication. They’re don’t have on-site customers or work in cross-functional teams. They don’t even finish all of their stories by the end of each Sprint, let alone deliver releasable software, and they certainly don’t use good engineering practices.
These teams say they’re Agile, but they’re just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It’s the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff–the stuff that’s really Agile–they’re setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won’t last.