Learning by Shipping

products, development, management…

Focusing on the work, not the methodology

with 25 comments

Want to get developers fired up? Kick off a debate about development methodologies – waterfall, agile, lean, extreme, spiral, unified, etc.  At any given time it seems one method is the right one to use and the other methods, regardless of previous experience, are wrong.  Some talk about having a toolbox of methods to draw on.  Others say everyone must adapt to a new state of the art at each generation.  Is there a practical way to build good software without first having this debate?

There’s a short answer.  Do what feels right until it stops working for the team as a whole, and to do so without debating the issue to death, then iterate on your process in your context.  The clock is running all the time and so debating a meta-topic that lacks a right answer isn’t the best use of time.  There’s no right methodology any more than there is a right coding convention, right programming language, or right user interface design.  Context matters.

We’re all quick to talk about experimentation with code (or on customers) but really the best thing to do is make some quick choices about how to build the software you need and run with it.  Tune the methods when you have the project results in the context of your team and business to guide the changes.  Don’t spend a ton of time up front on the meta-debate about how to do the work you need to do, since all you’re doing is burning clock time.


Building a software product with more than a couple of people over anything longer than a few months requires some notion of how to coordinate, communicate, and decide.  When you’re working by yourself or on a small enough codebase you can just start typing and what happens is pretty much what you would expect to happen.

Add more people or more time (essentially the same thing) or both and a project quickly changes character.  The left hand does not know what the right hand is doing or more importantly when.  The front and back end are not lining up.  The user experience starts to lack a consistency and coherency.  Fundamentals such as performance, scale, security, privacy are implemented in an uneven fashion.  These are just a natural outcome of projects scaling.

Going as far back as the earliest software projects, practitioners of the art created more formal methods to specify and implement software and become more engineers.  Drawing from more mature engineering processes, these methods were greatly influenced by the physical nature of large scale engineering projects like building planes, bridges or the computers themselves.

As software evolved it became clear to many that the soft part of software engineering could potentially support a much looser approach to engineering.  This coincided with a desire for more software sooner.  Many are familiar with the thesis put forth by Marc Andreessen Why Software is Eating the World (if not, worth a read).  With such an incredible demand for software it is no surprise that many would like projects to get more done in less time and look to a methodological approach to doing so.  The opportunity for reward for building great software as part of a great business is better than ever.  The flexibility of software is a gift engineers in other disciplines would love to have, so there’s every reason to pivot software development around flexibility rather than rigidity.


For this post let’s just narrow the focus to the ends of the spectrum we see in this dialog, though not necessarily in practice.  We’ll call the ends of the spectrum agile and waterfall.

In today’s context, waterfall methods are almost always frowned upon.   Waterfall implies slow, bureaucratic, micro-managed, incremental, removed from customers and markets, and more.  In essence, it feels like if you want to insult a product development effort then just label it with a waterfall approach.

Conversely, agile methods are almost always the positive way to start a project.  Agile implies fast, creative, energetic, disruptive, in-touch with customers and markets, and more.  In essence, if you want to praise a product development effort then just label it with an agile approach.

These are the stereotypical ends of a spectrum.  Anything structured and slow tilts towards waterfall and anything creative and fast tilts towards agile.  At each end there are those that espouse the specifics of how to implement a method.  These implementations include everything from the templates for documents, meeting agendas, roles and responsibilities, and often include specific software tools to support the workflow.

It is worth for a moment looking in a mirror and stereotyping the negative view of agile and the positive view of waterfall, just for completeness.  A waterfall project is thoughtful, architectural, planful, and proceeds from planning to execution to completion like a ballet.  On the other hand, agile projects can substitute chaos and activity for any form of progress—“we ship every week” even if it doesn’t move customers forward and might move them backwards.

Of course these extremes are not universally or necessarily true.  Even defining methodologies can turn into a time sink, so it is better to focus on reality of getting code written, tested, deployed/shipped and not debugging the process for doing so…prematurely.


In practice, no team maintains the character of the ends of this spectrum for very long, if ever.  There is no such thing as a pure waterfall project any more than there is a pure agile project.  In reality, projects have characteristics of both of these endpoints.  The larger or longer a project is the more it becomes a hybrid of both.  Embracing this reality is far better than focusing finite work energy on trying to be a pure expression of a methodology.

In discussions with a bunch of different folks recently I’ve been struck by the zeal at which people describe their projects and offer a contrast (often pointing to me  to talk about waterfall projects!).  One person’s A/B test is another person’s unfinished code in hands of customers.  One person’s architecture for the future is another’s slogging plan.  The challenge with the dialog is how it positions something everyone needs to do as a negative relative to the approach being taken.  Does anyone think you would release code without testing it with a sample of real people?  Does anyone really think that doing something quickly means you always have a poor architecture (or conversely that taking a long time ensures a good architecture)?

We all know the reality is much more subtle.  In fact, like so many product development challenges context is everything.  In the case of development methodologies the context has a number of important variables, for example some include:

  • Skills of team. Your team might be all seasoned and experienced people working in familiar territory.  You might be doing your n-th project together or this might be the n-th time building a similar project or update.  You know how hand-offs between team members work.  You know how to write code that doesn’t break the project.  Fundamentals such as scale, perf, quality are second nature.
  • Number of engineers / size of team.  The more people on a project the more deliberate you will likely need to be.  With a larger team you are going to spend time up front—measure twice, cut once.  The most expensive and time consuming way to build something in software is to keep rebuilding something—lots of motion, no progress. The size of the team is likely to influence the way the development process evolves.  On a larger team, more “tradition” or “convention” will likely be in place to begin with.  Questioning that is good, but also keeping in mind the context of the team is important.  It might feel like a lot of constraints are in place to a newcomer, especially relative to a smaller previous team.  The perspective of top, middle, bottom plays into this–it is likely tops and middles think there is never “enough” and bottoms think “too much”.  On a large team there is likely much less uniformity than any member of the team might think, and this diversity is an important part of large teams.
  • Certainty of project.  You might be working on a project that breaks new ground but in a way that is comfortable for everyone.  This type of product is new to the organization but not new to the industry (for example, a new online store for a company).  Projects like this have a higher degree of certainty about them than when building something new to the industry.
  • Size of code base.  Even with a small number of people, if you happen to have a large code base then you probably need to spend time understanding the implications of changes.  In an existing body of code, research has consistently shown about a 10% regression rate every time you make changes.  And keep in mind that “existing body of code” doesn’t have to mean decade’s old legacy code. It could just mean the brand new code the 5 of you wrote over the past six months but still need to work around.
  • Familiarity of domain.  The team might have a very high degree of familiarity with a domain.  In Dreaming in Code the team was very agile but struggling until they brought in some expertise to assist with the database portion of the project.  This person didn’t require the up-front planning one might think, because of the domain expertise they just dove right in building the require database.  But note, the project had a ton of challenges and so it isn’t clear this was the best plan as discussed in the book.
  • Scale services.  Scaling out an existing service or bringing up a new service for the first time is a big deal.  Whether you’re hosting it yourself or using a service platform, the methods you use to get to that first real world use might be different than those you would use for an app delivered through a store.  The interactions between users, security and privacy, reliability, and so on all have much different profiles when centralized.  Since most new offerings are a combination of apps and services, it is likely the methods will have some differences as well.
  • Realities of business.  Ultimately there is a business goal to a project.  It is easy to say “time to market is everything” and many projects often do.  But there is a balance to competitive dynamics (needing features) and quality goals (no one needs a buggy product) that really dictate what tolerances the marketplace will have for varying levels of quality and features one delivers.  Even the most basic assumption of “continuous updating” needs to be reconciled with business goals (something as straight forward as how to charge for updates to a paid app can have significant business implications for a new company).

The balance with all of these attributes is that they can all be used to justify any methodology.  If the team is junior then maybe more planning is in order.  If the project feels breakthrough then more agility is in order.  Yet as is common with social science, one can easily confuse correlation with causality.  The iPad is well-known to be almost a generation in the making (having started years before the iPhone then shelved).  Facebook is well-known to favor short cycles to get features into testing.  In neither case is it totally clear that one can claim the success of the overall effort is due to the methodology (causal v. correlation).  Rather what makes more sense is to say that within the context of those efforts the methodology is what works for the organization.

We don’t often read about the methodology for projects that do well but not spectacular.  We do read about projects that don’t do well and often we draw a causal relationship between that lack of success and the development methodology.  To me that isn’t quite right—products succeed or fail for a host of reasons.  When a product doesn’t do what the marketplace deems successful, the sequence of steps to build the product are probably pretty low down on the list of causal factors—quality, features, positioning, pricing, and more seem more important.

Many assert that you simply get more done using agile methods (or said another way, waterfall methods get less done) in a period of time, and given the social science nature of our work it is challenging to turn this assertion into a testable hypothesis.  We don’t build the same product twice (say the same way that carpenters know how to frame a house on schedule).  We can’t really measure “amount of work” especially when there can be so much under the hood in software that might not be visible or material for another year or two.

The reality of any project that goes to customers is that a certain amount of work needs to get done.  The methodology dictates the ordering of the work, but doesn’t change the amount of work.  The code needs to be written and tested.  The product needs to work at scale, reliable, secure, accessible, localizable, and more.  The user experience needs to meet the design goals for the product.  Over time the product needs to maintain compatibility relative to expectations—add-ins and customizations need to be maintained for example.

All of this needs to happen.  All of this requires elements of planning, iteration, prototyping, even trial and error.  It also requires a lot of engineering effort in terms of architecture and design.  On any project of scale, some elements of the project are managed with the work detailed up front.  Some elements are best iterated on during the course of the project.  And some can wait until the end where rapid change is not a costly endeavor.

There’s no magic to be had, unfortunately.  You can always do less work, but it doesn’t always take less time once the project starts.  You can’t do more work in less time, even if you add more resources. You can sacrifice quality, polish, details, and more and maybe save some time.  You can plan for a long time but it doesn’t change the amount of time to engineer or the value of real people using the product in real situations.  You can count of fixing things after the product is available to customers, but that doesn’t change the reality of never getting a second chance to make a first impression.  All of this is why product development is so fun—there simply aren’t magic answers.

There are ways to be deliberate in how you approach the challenge.

Checkpoints drive changes

Rather than advocate for a conversion of the whole team to a methodology or debate the best way to do the work, the best bet seems to always be much more organic.  On a small project, ask what would work for each of the team members and just do that.  On a large project, put some bounding principles in place and some supporting tools but manage by results not the process as best you can.

In all cases, the team should establish a rhythm of checkpoints that let everyone know where the project stands relative to goals.  Define a date along with criteria for the project at that date and then do an assessment.  This assessment is honest and transparent.  If things are working then great, just keep going.  If things are not working then that’s a good time to change.  The only failure point you can’t deal with on a project is a failure to be honest as a contributor and honest as a team.  If the dynamic on the team is such that it is better to gloss over or even hide the truth then no methodology will ever yield the results the team needs.

In projects I’ve worked on that have spanned from 3 months to 3 years, the only constants relative to methods are:

  1. Establish the goals of the project, the plan, in such a way that everyone knows the target—execute knowing where you want to end up and adapt when you’re not getting there or you want to adjust the target.
  2. Create a project schedule with milestones that have measureable criteria and honestly assess things relative to the criteria at each of those milestones.

The bigger the project the more structure you put on what is going on when, but ultimately on even the biggest projects one will find an incredible diversity of “methods”.  At least two patterns emerge consistently: (a) that scale services and core “kernel” efforts require much more up front planning relative to other parts of a project and failure to take that into account is extraordinarily difficult to fix later and (b) when done right, user experience implementation benefits enormously from late stage iteration.


Given all that is going on a project what’s the right way to approach tuning a methodology?

Very few software projects are on schedule from start to finish, and even defining “on schedule” can be a challenge.  Is a 10% error rate acceptable and does that count as on time?  If the product is great but was 25% late, time will probably forget how late it was.  If the product was not great but on time, few will remember being on time.

So more important than being on time is being under control.  What that means is not as much about hitting 4pm on June 17th, but knowing at any given time that you’re going to be on a predictable path to project completion.  Regardless of methodology, projects do reach a completion date—there’s an announcement and people start using what you built.  It might be that you’re ready to start fixing things right away but from a customer perspective that first new experience counts as “completing the project”.  Some say in the agile era products are never done or always changing.  I might suggest that whenever new codepaths are executed by customers the project as experienced some form of completion milestone (remember the engineers releasing the code are acting like they “finished” something).

The approach of defining a milestone and checkpoints against that milestone is the time to look at the methodology.  Every project, from the most extreme waterfall to the highest velocity agile project will need to adjust.  Methodologies should not constrain whether to adjust or not as all require some information upon which to base changes to the plan, changes to how people work, or changes to the team.

Checkpoints should be a lightweight self-assessment relative to the plan.  When the team talks about where they are the real question is not how are things going relative to a methodology but how things are going relative to the goal of the project.  The focus on metrics is about the code, not about the path to the code. Rather than a dialog about the process, the dialog is about how much code got done and how well is it working and connecting to the rest of the project.

That said there are a few tell-tale signs that the process is not working and could be the source of challenges:

  • Unpredictable.  Some efforts become unpredictable.  A team says they are going to be done on Friday and miss the date or the team says a feature is working but it isn’t.  Unpredictability is often a sign that the work is not fully understood—that the upfront planning was not adequate to begin the task.  What contributes to unpredictability is a two-steps forward, one-step back rhythm.  Almost always the answer to unpredictability is the need to slow down before speeding up.
  • Lots of foundation, not a lot of feature.  There’s an old adage that great programmers spend 90% of the time on 10% of the problem (I once interviewed a student who wrote a compiler in a semester project but spent 11 of 12 weeks on the lexical phase).  You can overplan the foundation of a project and fail to leave time for the whole point of the foundation.  The checkpoint is a great time to take a break and make sure that there is breadth not just depth progress.  The luxury of time can often yield more foundation than the project needs.
  • Partnerships not coming together.  In a project where two different teams are converging on a single goal, the checkpoint is the right time to sanity check their convergence.  Since everyone is over-booked you want to make sure that the changes happening on both sides of a partnership are being properly thought through and communicated.  It is easy for teams that are heads down to optimize locally and leave another team in a tough spot.
  • Unable to make changes.  In any project changes need to be made.  Surprisingly both ends of the methodology spectrum can make changes difficult.  Teams moving at a high velocity have a lot of balls in the air so every new change gets tougher to juggle.  Teams that have done a lot of up front work have challenges making changes without going through that process.  In any case, if changes need to be made the rigidity of a methodology should not be the obstacle.
  • Challenging user experience.  User interface is what most people see and judge a product by.  It is sometimes very difficult to separate out whether the UI is just not well done from a UI that does not fit well together.
  • Throwing out code.  If you find you’re throwing out a lot of code you probably want to step back—it might be good or it might be a sign that some better alignment is needed.  We’re all aware that the neat part of software is the rapid pace at which you can start, start over, iterate, and so on.  At some point this “activity” fails to yield “progress”.  If you find all or parts of your project are throwing out more code, particularly in the same part/area of a project then it is a good time to check the methodology.  Are the goals clear?  Is there enough knowledge of the outcome or constraints?
  • Missing the market. The biggest criticism of any “long” project schedule is the potential to miss the market.  You might be heads down executing when all of a sudden things change relative to the competition or a new product entry.  You can also be caught iterating rapidly in one direction and find competition in another.  The methodology used doesn’t prevent either case but a checkpoint offers you a chance to course correct.

It is common and maybe too easy to get into a debate about methodology at the start of a project or when challenges arise.  One approach to shy away from debates about characterizing how the work should be done is to just get some work done and iterate on the process based on observations about what is going wrong.  In other words, treat the development process much like the goal of learning how to improve the product in the market place through feedback.  A time to do this is at deliberate checkpoints in the evolution of the process.

So much of how a product evolves in development is based on the context—the people, the goals, the technologies—using that to your advantage by knowing there is not a high degree of precision can really help you to stay sane in the debates over methods.

This post was challenging to write. It is such a common discussion that comes up and people seem to be certain of both what needs to be done and what doesn’t work.  What are some experiences folks have had in implementing a methodology?  What are the signs you’ve experienced when regardless of the methodology the project is not going in the right direction? Any ideas for how to turn checkpoints into checking up on the project, not revisiting all the choices? (ok that last one is a favorite of mine and a topic for a future post).



Written by Steven Sinofsky

February 7, 2013 at 8:30 am

Posted in posts

Tagged with , , , ,

25 Responses

Subscribe to comments with RSS.

  1. MSM can be an organic substance which contains sulfur.


    December 21, 2014 at 3:38 am

  2. Smokefree home. Open to Buy it now provides. Far better sign into or first.
    You will get 15 from your own purchase.

  3. Have you ever thought about piisblhung an ebook or guest authoring on other websites?I have a blog based on the same information you discuss and would love tohave you share some stories/information. I know my visitors would value your work.If you’re even remotely interested, feel free to send me an e-mail.


    August 5, 2013 at 11:25 pm

  4. It’s in point of fact a nice and useful piece of info. I’m happy that you simply shared this helpful info with us.
    Please stay us up to date like this. Thanks for sharing.


    July 23, 2013 at 9:19 am

  5. I am genuinely grateful to the holder of this website who has shared this enormous
    post at here.


    April 20, 2013 at 4:33 pm

  6. Wow, what web hosting provider have you been using? Site came up super fast and there
    was no lag in any way. I only ask because my web hosting provider stinks hugely.
    Ok, thank you! Great article by the way!

    check this out

    March 26, 2013 at 12:31 am

  7. guy, not a FOSS guy . I have tried to make this clear to people in the past (see this video as an exmpale), but of course some people ignore facts in favour of their own


    March 11, 2013 at 2:32 pm

  8. Good talk overall. A few comnmets1. Your points are valid but you have a choice of how those points are presented positively or negatively. The overall tone of your talk is more negative but it could easily be flipped and be inspiring. Rather than drawing scenarios that will lead to failure, answer the question of HOW they can be successful. You have some examples of that but if you are truly wanting to change the mindset then that has to be the major focus.2. You are right about the funding game. Too many people play the game of valuation rather than value. I have gotten sucked into it myself.3. Another theme you can expound on (with appropriate credits to me for this ) engineers solve problems, innovators create opportunities . Unfortunately the root of evil here lies in our education system that does everything possible to suppress creativity and does everything possible to turn us into non-thinking functionaries. There is no focus on actually addressing problems or needs. In fact not even being aware of them.4. Write THE book.


    March 11, 2013 at 12:08 pm

  9. Good points in this post. Thanks!


    March 4, 2013 at 4:37 pm

  10. Context matters, indeed. As long as the public interface of a development team to end-users is a stable stream of business value then it is very healthy to internally debate, early and often, all the issues —usually there are no shortage of them. Sometimes there are good practical answers which remove the root cause of an issue, other times there isn’t; for those cases, where practical answers are just palliatives, there is need for new theoretical answers that spring new breeds of practical answers. For example, the practical answers coming from an empirical workview (“workview” in analogy with worldview).

    Marco Dorantes

    February 12, 2013 at 10:15 am

  11. Great post & I think a brave topic to tackle. You are very right that Agile methods get a good press, but are by no means a particularly high predictive indicator of success compared to factors like team cohesion, meaningful customer enagagement, & basic delivery disciplines. I can think of several high profile projects that sank with agile approaches that never made it out of weekly build cycles into a viable solution for the customer. Maybe next week you will tacke coding conventions as a topic that generates religious debate but not much customer value. :-)


    February 12, 2013 at 7:38 am

  12. I enjoyed reading this post as it supports a couple of ideas I have been having lately.

    It also reminds me a of a quote or saying, but I’m not sure who the source is
    “People shouldn’t serve the system, the system should serve the people.”


    February 12, 2013 at 1:38 am

  13. Thank you for this post.
    I’m adding it to my short list of things I tell new managers to go read.

    Mason Bryant

    February 10, 2013 at 10:00 am

  14. I think one tell-tale sign you have a problem is when following the methodology has higher priority than the project’s goals. A methodology with a lot of ceremony around it has a higher risk of falling into this trap.

    When the project becomes “completing milestones” or “putting stories in done” it is very easy to miss the broader view, that is why. Why are we completing milestones and stories, for whom are we trying to solve what problem. In my world agile is not what you define it to be, to me it is to often and continuously connect with the real world problem and there is no better way in my mind to do that than with executable code in the hands of those that should use it. There is no plan, architectural drawing or power point presentation that will ever beat a tangible approach. Sometimes you can’t get there though. Completing a milestone is not a goal of any project, but it is easy to think so, the milestone is just there for assessment of progress and it is supposed to be honest.

    Shipping every week at least gives you the certainty that you have workable code through out the project, it makes sure you have automatic deployment and testing in place, or you can’t accomplish this. These are all good risk reducers on the technical side.

    You started your article off by mentioning that software has one up on other disciplines as it can change rapidly. I think the best any software project can do is to be set up as optimal as possibly to handle changes not trying to control them.

    I think it would be foolish to no apply a methodology that does put a emphasis on iteration to software development.

    I think the biggest risk in a software project aren’t technical, careful staffing, reasonable approach to automated testing and deployment goes a long way to reduce technical risks, but knowing which problem to solve is paramount and there seems to be no scientific method to apply to that problem.

    I am a valid believer that “more can be done with less people”, try not to get into the situation where your left hand doesn’t know what your right hand is doing, it will impede your organization’s ability to embrace change.

    To have a project that handles change rapidly will make it easier to quickly adapt your software after it has shipped, because this is were you need to adapt quickly and if you have the foundations already in place to quickly deploy changes you can keep the momentum of your SW release going.

    WIndows 8 for instance had momentum when it launched, if that momentum had been followed up by many small incremental updates since launch the industry would likely put more faith in it as it builds trust to ship. Instead everyone is waiting for that big update, that big announcement.

    Same goes for projects, many small updates are better than a few big milestones. Sure it is harder, and you will hear complaints that you never have some peace and quiet to actually “do all the large restructurings that are “necessary””, the trick is to be able to do the large things through many small ones, which is actually harder to “plan” as you need a good and clear vision of what you want, instead of a plan of what to do.

    But if there was one good way of doing things we wouldn’t even discuss this so in the end, the advice you start off with, doing what feels good and is working for your team, is likely better than forcing conformity.

    I would however strongly recommend that whatever ways of working you use, adopt a reoccurring event where you reflect and adapt your ways (Scrum retrospect). Otherwise you won’t even know you have things that needs tuning, or even worse, things that don’t need tuning that gets tuned.

    Niclas Lindgren

    February 9, 2013 at 4:33 am

  15. 1. Make your vision, strategy, and architecture explicit; update them as you learn, and use them to keep your team or team-of-teams aligned.

    2. The optimal development process is iterative, and risk resolution is the optimal iteration driver. “Attack your risks, or they will attack you” – and at the worst possible time.

    3. The primary sources of risk are requirements uncertainty, architectural uncertainty, technical novelty, user experience, dependencies among teams, and politics.

    4. Build and test continuously, correcting all defects as they’re discovered: not just “severity 1” defects, *all* defects.

    • With aggressive testing, many defects can be discovered during the iteration in which they are created; immediately correcting them reduces subsequent developer interrupts, a significant contributor to new defect creation.

    • Establish a mechanism that makes updates immediately available to users, but allows them to choose when to accept these updates.

    • Provide a forum that enables users to report defects, relate their experience with updates, and suggest improvements. Immediately correcting defects reported by users forges a constructive community, replacing product quality with product improvement as the primary topic of conversation. Implementing user-suggested improvements that are consistent with your vision and strategy produces an enthusiastic community of evangelists.

    5. Staff carefully, as no process can compensate for bad judgment or poor leadership.

    Dave Bernstein

    February 8, 2013 at 10:14 pm

  16. about “people avoiding responsibilities by not taking initiatives when the project is not going in the right direction” : I want to add that this happen when the management is not doing his job and puts pressure on the engineers.


    February 8, 2013 at 9:01 am

  17. Once again thanks for this great post.
    Some thoughts :

    – I have worked with waterfall and agile methodology, and I have encountered success and failures with both. I agree with you, the context of the project and the people are more important than the methodology.
    The problem I face is that some people can be very stubborn on the methodology to use (or which langage/framework/OS …) because of the previous success or failures they had in their carrier. Any ideas on how to deal with this problem ?

    – “What are the signs you’ve experienced when regardless of the methodology the project is not going in the right direction?” => People avoiding responsibilities by not taking initiatives (you have to tell them exactly what they have to do and they won’t do anything else). Someone coined the term “cover your as* development” for this behaviour (I may have read this in a Dilbert strip).

    – “Any ideas for how to turn checkpoints into checking up on the project, not revisiting all the choices?” => where I work we have a sort of “list of things to do” (with priorities).
    Every once in awhile we go through the items of the list and we remove the ones that have been done.
    There are often tasks where there are problems because the engineer working on it does not have enough information. We specify in more detail this task immediately. If the problem is technical, most of the time another engineer will be able to help.
    During the checkpoint, new tasks are added to the list (because of feedback from the users or because one the tasks is divided into subtasks). Finally the new tasks on the list are assigned.

    – “All of this is why product development is so fun—there simply aren’t magic answers.” => If this were the case, robots would be doing our work :)


    February 8, 2013 at 8:50 am

  18. Great post S. Sinofsky!

    I’ve seen most projects benefit from having a framework for setting priorities, a way to do work stream tracking and organisation, team and individual accountability, paced and reliable results, high bandwidth of communication, information transparency and availability, decision awareness, etc.

    Methodologies work towards providing a structure to support this. My view is that the way that structure is setup (agile or waterfall) shouldn’t really matter.

    Agile (scrum) does it with physical cards on the wall, daily rhythmic accountability, information radiators such as the board and the burn down and a backlog.

    Waterfall does it with by phase sign-off, deliverable templates (“if only i search long enough i’ll find the right one!”) and heaps of more up-front thinking and detail on each project phase.

    What each framework promotes is more upfront thinking & less flexibility to change and still meet the objectives VS enough upfront thinking & enough flexibility so that you meet some objectives. (you ship the software you have, not always the one you want)

    In short:

    – If you’re building a world dominating robot, maybe you’d benefit from a bit more of upfront thinking before you announce yourself on TV after getting it to kill a fly at the end of sprint 2.

    – If you’re building on uncertainty, iterate.

    – Hardly any problem you’re building has enough uncertainty that it promotes that you don’t do enough upfront thinking.

    – Plans, High level designs, Architecture diagrams, are not there to limit adaptability or change – they’re there to promote enough upfront thinking so you have a framework to make decisions, setting priorities.

    – These bullet points are not the point! :)

    Keep the posts coming!

    Ricardo Clerigo

    February 8, 2013 at 8:15 am

  19. Hi Steven,

    Great article. Its great to hear a voice of reason amid the debates about the “best” methodology. I believe, with only my own experience as evidence, that a well managed project will be successful regardless of the development methology. Waterfall and JGTJD (Just Get The Job Done) have worked fine for me, especially when either working alone or with an experienced technical lead.




    February 8, 2013 at 8:05 am

  20. Hours after I drafted out my opinions and thought on means and end, consequentialism and non consequentialism, I got e-mail notification about your blog post and got some extra ideas that improved my essay a bit. Thank you Steve, your blog taught me things I will find precious throughout my career.



    February 8, 2013 at 6:55 am

  21. My experience of running software and infrastructure projects in different parts of the globe (specifically – Central Europe, Singapore, Mexico and the UK) indicate social-cultural aspects of the team must be taken into account. Any one method does not cover all members of a team, and the method must meld to the way the locals think, respond to advice and leadership.
    Unfortunately my experince is our western centric methods are imposed on others, so even the definition of work can be a misinterpreted to the detriment of the project and leader.
    Could the methodologies mentioned here, and used by USA/UK based companies be wrong for multicultural teams?

    Mike Knight (@QuijoteMike)

    February 8, 2013 at 6:04 am

  22. Great blog. You would think that if one methodology was so superior that there would be plenty of studies proving it. But there aren’t. Which proves that all the methodology debates are about style, not actual substance. The same can be said for O-O and all the various frameworks. Actually, I would like you to address those topics next. Is your language the best? Then where’s the proof? Does O-O improve software quality, speed development, make coders and designers more productive, or even insure reusablity more that any other paradigm? If so, there should be research demonstrating that is the best. Love your framework? It’s not just a fad, right? So how do I know it is the best way to develop? This industry is so full of hype and so low on facts while these debates rage on.


    February 8, 2013 at 5:23 am

  23. Hi Steven,
    I think the tell-tale signs of a process not working that you’ve outlined is spot on. Also, I’ve wondered if it is an issue of methodology if team members are frequently dodging responsibility.


    February 8, 2013 at 2:59 am

  24. By any means? Well, that’s exactly the way to ship crap…
    The thing is, to be really good, you have to be good at both things: in practice AND in theory (and you have to balance both).
    The bigest problem is that so many developers are good only in one of the above….


    February 8, 2013 at 2:21 am

  25. Hi Steven,

    Many thanks for the blog. I come from the world of IT infrastructure where the method I’ve been involved in most is waterfall and I have implemented this methodology at a company. It was based on one I ‘borrowed’ from my previous company, nothing revolutionary; primarily a light-weight version of Prince2. It has been interesting to see how the same methodology is viewed in both organisations; and how it needs to be adapted to be successful based upon the company culture.

    In one organisation it was a framework that was applied to everything from software development to logistics and finance and became engrained in the DNA of the business. Standard stages were used for each project with decision points at the end of each stage. However sometimes the decision points became a hurdle that you spent more effort on preparing for than driving the project forward. With my new organisation it was a means to bring some rigour to project delivery. Some people were resistant to the new ideas and adoption became a challenge. However as projects became more predictable, or at least more understood, the adoption increased. Decision points in this organisation were far more informal and trust based, a positive of this was that things got done quicker, down-side was the quality wasn’t always there. I learnt whilst trying to rollout a methodology that listening to what people want is more important than me coming up with my method, and the more stringent I get the more resistance I encounter.

    I have also worked with developers and encountered their resistance to waterfall, I can get the sense that it feels the end is too far off some times… I haven’t managed an software project yet but I think it would be interesting learning experience. I like your more receptive approach of speaking to the team and finding out what works for them. It also sounds to me that you are advocating a lack of traditional methodology just a practical approach to achieve results? Oh, and I like the phrase framework rather than methodology as it sounds less prescriptive, what do you think? There are so many factors that determine success in a project but have you ever found the methodology being the key factor for success or failure?

    Once again thanks for the interesting points….



    February 7, 2013 at 11:07 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: