No matter what framework or method your management thinks they are applying, learn to work this way: Produce running, tested, working, integrated software every two weeks, every week. Build your skills until you can create a new fully operational version every day, twice a day, multiple times a day. Keep the design of that software clean. As it grows, the design will tend to become complex and crufty. Resist and reverse this tendency consciously, refactoring in tiny continuous steps, all the time, so that your rate of progress is as steady and consistent as possible. Use the current increment of software as the foundation for all your conversations with your product leadership and management. Speak in terms of what’s ready to go, and in terms of what they’d like you to do next. This is the development team’s best hope for a reasonable life. By keeping the software always ready… Read more →
EppsNet Archive: Methodology
How’s That WBS Working for You?
Michael James posted this annotated job listing in the Scrum group on Yahoo . . . [Redacted] is looking for a dedicated and experienced application developer [blah blah blah] to ensure delivery of high quality artifacts, to adhere and to follow [Redacted]’s SDLC. This is an excellent opportunity [blah blah blah] well-known Fortune 50 company. Tasks and responsibilities [clip] Provide accurate and timely estimates (work breakdown schedules) Must have proven ability to provide project estimates and work-breakdown schedules And you know these guys are getting great results from their precise WBS and SDLC because of these lines: Must be extremely responsive, able to work under pressure in crisis with a strong sense of urgency 24/7 on call responsibilities on a rotational basis Read more →
Scrum Doesn’t Do Anything
In the end it doesn’t matter what names you use for your processes, good people will do good work and continuously improve what they do. So much of the discussion around Lean versus Scrum (etc.) is about marketing hype, selling consulting and training services, and cornering the market with new name-brands. . . . Scrum is not a methodology, it is not a process. It is a simple framework underpinned by some common sense principles. Scrum offers individuals and organizations the opportunity to continuously improve the way they work. It provides a space for people to behave like human beings, with trust, respect and passion. That’s about it. But that is huge. — Tobias Mayer Read more →
Waterfall: The USSR of Software
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. — Ken Schwaber Read more →
Antipattern: Exactly on Schedule
I work with a company that has the following set of milestones in its standard project methodology: Vision/Scope Complete Requirements Complete Design Complete Definition Complete Build Complete Test Complete Rollout Complete I’ve noticed an interesting pattern at the weekly enterprise status meetings: a significant number of projects report being exactly on schedule for each milestone — not one single day ahead or behind! — until they get to rollout, at which point they suddenly go several months late. Some things can be faked and some things can’t. As long as you have milestones that can be met simply by declaring them done, or by signing off on a document, you can always hit them on time. But when it comes to putting actual working software in front of a customer, that’s when you really have to deliver the goods, and that’s when the milestones start getting missed. This is a… Read more →
How Long Should it Take to Define a Project?
Project X hit a milestone called Vision/Scope seven months ago, 99 days late. It’s 312 days late on the current milestone, which is called Definition. To date, the project has consumed 36,000 labor hours — 18 person-years — and $2.5 million. At this morning’s enterprise-level status meeting, it was decided that Project X will be put on indefinite hold, as it is no longer a strategic priority. This reminded me a lot of an article I read a few days ago: What the waterfall does well is to keep useless projects from resulting in useless code that needs to be maintained. I’m not sure if that’s the real purpose, but it’s certainly a great side benefit. It may sound inefficient to pay a lot of engineers to get started on projects, do a bunch of analysis and design, and finally abandon the whole thing when something else becomes a higher… Read more →
A Forceful Dose of Reality
. . . there is nothing like a tested, integrated system for bringing a forceful dose of reality into any project. Documents can hide all sorts of flaws. Untested code can hide plenty of flaws. But when people actually sit in front of a system and work with it, then flaws become truly apparent: both in terms of bugs and in terms of misunderstood requirements. — Martin Fowler, “The New Methodology” Read more →
A Methodology Question
Let’s say your software development methodology tells you to do A, then B, then C, then D, and so on, until you get to Z, at which point, you’re done. And let’s say you do A, then B, then C, then D, and you notice that your project is not going according to plan for reasons that appear to be related to the methodology. What do you do? Do you forge ahead with E, F and G, even though that now looks like the wrong thing to do? If you’re committed to the methodology, you have to, right? Or — do you fall back on the knowledge and experience of the project manager and the project team, and rely on them to do the right thing? And if you can rely on the knowledge and experience of the project team now, what was the point of the methodology in the… Read more →
Respect the Classics, Man: No Silver Bullet
This essay by Turing Award-winner Fred Brooks is almost 20 years old now. Sadly, the ideas on incremental development are still considered outside the mainstream in IT, which continues to favor the widely-discredited waterfall approach. Read more →
The Waterfall Approach Persists as an Urban Myth
Much of present-day software acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy. — Fred Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering” We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s Service Bureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural . . . All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something… Read more →
The Comfort of Methodology
Ill-specified systems are as common today as they were when we first began to talk about Requirements Engineering twenty or more years ago. Yet the task of creating complete and perfect specifications is not rocket science. We have adequate and comprehensible theories at our disposal for specification of finite state automata. We have proceeded over the past decades to develop and refine a discipline of applying these theories to real-world systems. In our methodological focus, we may have lost sight of some endemic problems that plague not the process but the people who do the process. Is it possible that an engineering approach to requirements is as badly suited to our real need as would be an engineering approach to raising teenagers? I’m beginning to think so . . . — Tom DeMarco, “Requirements Engineering: Why Aren’t We Better at It?”, 2nd International Conference on Requirements Engineering There are zillions… Read more →