Agile development isn’t a thing you do, it’s an attitude, it’s a set of personal values about responding to the real world, being open to the information that is there and being willing to do something about it.
You begin by stating that agile is basically three things: a set of engineering best practices that allow for rapid delivery of high-quality software, a project management process that encourages frequent inspection and adaptation, and a leadership philosophy that encourages team work and accountability.
You go on to say that success in today’s economy requires us to respond quickly to changing market conditions. Agile processes allow our teams to meet the changing demands of their customers while creating environments where top developers want to work.
The most common verb associated with requirements is “gather.” Yet most requirements that end up fulfilled in a system aren’t gathered. Yes, I know, there are always a few requirements that are so obvious in a new system that you can “gather” them from stakeholders, but gathering implies that the requirements are already out there, fully formed and fully understood, and ready for harvest. It just doesn’t work that way. No stakeholder ever says to an analyst, “Requirements? Why, yes, I have eleven requirements. Eight are functional, one is a usability requirement, and the other two are operational requirements. Are you collecting constraints now, as well? I have three of those. Please sit down, and I will elucidate perfectly clearly on each and every one in turn.” Most requirements are discovered–or invented. Many are transformed or compromised along the way.
Most stakeholders don’t consider the underlying requirements of their work; they do their work. They are not in the business of reinventing the work. The arrival of a new project is the point in time when the ideas for new possible ways of doing work force us to consider the underlying requirements. If you go to an experienced front-desk hotel employee and ask what requirements there are for the check-in process, you are most likely to hear in excruciating detail exactly how the check-in procedure works today. Indeed, you will probably hear more than just about check-in; you will hear about the reservation procedure and how it impacts the check-in procedure. It never crossed the mind of that employee to consider what information and material goods the hotel needs in order for a guest to do self check-in with a new automated system. And the idea of the guest selecting a room from all those available is a shock. It’s not done that way!
This is why we have folks with “analyst” in their titles. Analysis is never simply about recording requirements from clients and other stakeholders. Analysts are not waiters who take orders without comment. Analysts need to learn how to tease out the basic rules–the policies–of the system and liberate all stakeholders from thinking that the new system should be based on current procedures. It is invention that is at the heart of analysis, not gathering.
A thought exercise: “How long will it take you to get to work tomorrow? Can you guarantee it? To give us a guarantee, you’d probably put a buffer on your answer first. I guarantee a team working to put together software for the next two weeks is engaged in something a lot less well understood than a daily commute. We can put in a buffer - promise less - to give you a guarantee, or we can work from our estimates and do our best.”
Think of waterfall as being similar in concept to the old USSR central planning of the economy. Think of Scrum as similar to a market economy.
Great sequence of posts on the scrumdevelopment Yahoo group . . .
Person A says the number one rule of business is that the customer is always right.
Person B says the customer is NOT always right, like his customer who wants an auction system like eBay on a budget of $1,500.
Person A says Person B needs to shut up and listen to the customer.
I AM listening. They want something like Ebay for $1500. They want me to build a full Ebay clone this weekend and then tweak it until they’re happy over the next two weeks. I have listened carefully and diligently and have confirmed multiple times. This is definitely what they want. They’d also like time travel, but they don’t need that until April.
The point I’m making is that there are many reasons why just listening to your customer and giving them what they ask for is often not a good idea - for you or for the customer.
I was typing in Microsoft Word and I started a bulleted list with an item like this:
Then I hit the Enter key.
What do you think happened?
Not only did I get another bulleted list item, Word set the font to bold!
So I typed this:
And as soon as I typed the period, Word turned bold off!! Not only did it figure out that I’m creating a bulleted list, it figured out that I’m starting each bullet with bold font, followed by a period, followed by more text in regular font, and it takes care of everything for me automatically! That’s pretty sophisticated.
Compare that to Lotus Notes, which can’t even figure out when I hit Enter twice that I want to turn the bullets off!
We use Notes at work and I swear to God, if I type a bulleted list and hit Enter twice, Notes gives me this:
I actually have to turn bulleting off manually! Does anyone really want to create a bulleted list with multiple empty items?
I’ve never seen another text editor do something this stupid . . .
I’m working with a company that uses Lotus Notes. It’s been more than 10 years since I’ve had to use Notes and it’s as bad as ever. It’s probably the worst piece of software ever released by a major company.
The worst feature — well, it’s hard to pick a worst feature, but one of the worst features — because I have to deal with it dozens of times a day — is the way Notes makes me reply to email. I can’t just click Reply and start typing. When I click Reply, I get a dropdown list of options and have to select one:
- Reply
- Reply with History
- Reply without Attachment(s)
- Reply with Internet-Style History
The godawful thing about this is that default options for email work 100 percent of the time. I always want to reply with history and without attachments, so why give me a bunch of options that I don’t want and make me explicitly select one every time?
Why would I not want to reply with history? If I’m sending replies without including the original email for context, most people send and get way too much email to remember what the heck I’m responding to.
And why would I send an attachment back to someone with my reply? They already have the document. They sent it to me. They don’t need another copy of it. But every day I see emails going back and forth across the network with multi-megabyte attachments because people have to explicitly select an option to remove it.
The average software developer reads less than one professional book per year (not including manuals) and subscribes to no professional magazines. These developers are not developing or advancing themselves professionally. About 75% of these people do not have a degree in computer science or a related field. They learn by trial-and-error and on-the-job training, which means that they risk learning other people’s bad habits rather than industry best practices. This method of professional development perpetuates ineffective, inefficient practices that hinder the success of software projects.
Tell me something I didn’t know!
Thus spoke The Programmer.
The most common reason for software project failure is attributed to requirements issues – badly defined, not stated correctly, changing requirements, etc.
Any project I’ve done that lasted longer than a day had changing requirements. If your development strategy only works with an unchanging set of requirements, you need to rethink your approach . . .
Jerry Weinberg has suggested that “it works” may mean “We haven’t tried very hard to make it fail, and we haven’t been running it very long or under very diverse conditions, but so far we haven’t seen any failures, though we haven’t been looking too closely, either.” In this pessimistic view, you have to be on guard for people who say it works without checking even once to see if it could work.
“No user would do that” really means “No user I can think of, who I like, would do that on purpose.”
Who aren’t you thinking of?
Who don’t you like who might really use this product? What might good users do by accident?
In general it can vastly simplify testing if we focus on whether the product has a problem that matters, rather than whether the product merely satisfies all relevant standards. . . . Instead of thinking pass vs. fail, consider thinking problem vs. no problem.
Instead of “managing” the process in the traditional sense, management can help a lot more by:
- realizing that it is the teams that will discover and make the improvements, not management,
- giving teams the responsibility to manage and improve their own process as well as the freedom and authority to do so,
- establishing an environment that actively encourages teams to be totally honest about their problems and impediments,
- listening to what the teams say they need and respond to those needs,
- observing teams in action instead of just collecting numbers,
- providing useful feedback to teams instead of instructions or pressure.
If . . .
- you are able to get important things done
- you are seen learning things on your own
- you are seen trying to do things even if you aren’t sure how
- you share freely the things that you know
- you don’t hide your ignorance, but also don’t rest on it
- you honor what other people know
- you know more often than not how to find out what you don’t know
- you know how to ask for help
- you offer to help people on their own terms
Then . . .
- no one will care whether you succeed by learning or succeed by already knowing
- no one will care if you mess up occasionally because they assume you learn from it
- no one will mind if you forget (or don’t know) any given fact or method at any given time
- you will be treated as if you’re smart and useful, even though everyone knows you have a lot to learn
A “spec” is close to useless. I have _never_ seen a spec that was both big
enough to be useful _and_ accurate.And I have seen _lots_ of total crap work that was based on specs. It’s
_the_ single worst way to write software, because it by definition means
that the software was written to match theory, not reality.So there’s two MAJOR reasons to avoid specs:
- they’re dangerously wrong. Reality is different, and anybody who thinks
specs matter over reality should get out of kernel programming NOW.
When reality and specs clash, the spec has zero meaning. Zilch. Nada.
None.It’s like real science: if you have a theory that doesn’t match
experiments, it doesn’t matter _how_ much you like that theory. It’s
wrong. You can use it as an approximation, but you MUST keep in mind
that it’s an approximation.- specs have an inevitably tendency to try to introduce abstractions
levels and wording and documentation policies that make sense for a
written spec. Trying to implement actual code off the spec leads to the
code looking and working like CRAP.The classic example of this is the OSI network model protocols. Classic
spec-design, which had absolutely _zero_ relevance for the real world.
We still talk about the seven layers model, because it’s a convenient
model for _discussion_, but that has absolutely zero to do with any
real-life software engineering. In other words, it’s a way to _talk_
about things, not to implement them.And that’s important. Specs are a basis for _talking_about_ things. But
they are _not_ a basis for implementing software.So please don’t bother talking about specs. Real standards grow up
_despite_ specs, not thanks to them.
Many wise people have said that what you put your attention on is what you will create around you. This is true in project management. If you concentrate on meeting the plan and slipping when big problems arise, you will, at best, ship on time, and more likely, you will ship late. . . .
To change your results by changing the way you look at how your team uses time, you must put your attention on how to make tasks take the least time possible. Replace “sticking to the plan” with “looking for ways to decrease the time spent.”
I work in the IT department of a health care organization. I’ve noticed before that health care professionals are much better than IT professionals when it comes to setting the expectations of customers.
Last week, I found a handbook around the office called Risk Prevention Skills: Communication and Record Keeping in Clinical Practice. Substitute “customers” for “patients” and “software development” for “medical care” and you can apply the same advice to IT:
Some patients are unreasonable in their expectations of medical care. . . . If a complication does occur, the patient or family with unreasonable expectations will usually conclude that someone must have done something wrong and should be blamed. The only way to correct unreasonable expectations is to accurately explain to the patient, before care is provided, what problems may be encountered.
An accurate description of the range and likelihood of possible outcomes, and the reasons why an unsatisfactory result can occur, may be the most important elements of an informed consent.
I hold in my hand a 63-page requirements doc . . .
We spend a lot of time reworking the requirements doc to reflect the reality of the system that we’re actually building. We also spend a lot of time reworking all the docs that derive from the requirements doc — design docs, UI docs, test plans, etc. — to reflect the changes in the requirements doc.
Another way to think of this is that the project is driving the requirements, rather than the requirements driving the project.
So why did we create all these incredibly detailed documents?
We have a vast collection of well-documented ignorance . . .
Thus spoke The Programmer.
- We increase return on investment by making continuous flow of value our focus.
- We deliver reliable results by engaging customers in frequent interactions and shared ownership.
- We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
- We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
- We boost performance through group accountability for results and shared responsibility for team effectiveness.
- We improve effectiveness and reliability through situationally specific strategies, processes and practices.
There’s an old saying that you get what you measure . . .
I recently asked a colleague whether he would prefer to deliver a project somewhat late and overbudget but rich with business benefits or one that is on time and underbudget but of scant value to the business. He thought it was a tough call, and then went for the on-time scenario. Delivering on time and within budget is part of his IT department’s performance metrics. Chasing after the elusive business value, over which he thought he had little control anyway, is not.
Some ideas. . . .
Don’t argue about things that don’t exist, like whether Save buttons should do this or that. Instead, code or prototype it and then team members use it themselves. You’ll be able to tell if it could be better when you use it instead of talk about it. . . .
One of the biggest blockers to team greatness is that members of team will have really good team diagnoses but they don’t say them out loud. So nothing can be done with the idea. You gotta say your great ideas out loud. . . .
Stay out of the content. The real issues are not about UI and architecture. Those are just the excuses to act out team neuroses. . . . If you resolve the interpersonal issues you won’t feel like you have UI or architecture issues.
Processes and planning will not make this better. They will make it worse. Don’t have a meeting to discuss how you will do the UI, for instance. That’s one of the worst things you can do. Don’t talk about stuff that doesn’t exist. Make stuff and then perfect it.
