Microsoft and Scrum

I read a recent entry from Brian Harry’s blog on the next Visual Studio release, with a Scrum template and tool support. Brian is Product Unit Manager for Team Foundation Server and a Microsoft Technical Fellow. He also led the charge to use Scrum throughout TFS and has been instrumental in the inclusion of Scrum on VS 2010.

However, in his blog he has misinterpreted or misunderstood some key Scrum and Agile concepts. Many people do the same, but Brian’s influence is widespread and seen in the implementation of Microsoft products. I feel a need to address these conceptual flaws.

I’ve been nervous for a while about how well people would understand self-organizing Scrum Teams and the development teams within. Our tendency and tooling from waterfall and predictive processes is to view people as assignable, parsed, optimized resources. This works great if you are running a factory line and people are doing simple work. It really sucks if you are trying to do creative, complex work where there are many competing ideas and solutions emerge from interactions. The Agile Manifesto reflects this in “Individuals and Interactions over Processes and Tools.”

The new VS measures a person’s available capacity. You have to wonder. People don’t have measurable capacities when they are performing intellectual, creative work. Things move back and forth between different parts of the brain and some of the best ideas come at 2:00am in bed.  Scrum and XP are sneaky. A team of people sign up to solve problems within a Sprint. They are engaged in group problem-solving for the duration, and the problem never leaves some part of their brain. They are engaged. Brian’s comments and the consequent tooling reminds me of ideal days: a person is only working when his or her fingers are on the keyboard.

Last, but I’m sure I’ve missed others, is the idea of “assigned” work. This is a common smell of a development team that is not self-managing. Who “assigns” work if a development team is self-organizing? Development teams select work, figure out how to do it, and go do it. Assignments are a dysfunction.

In my measurements, self-organization is a prerequisite for Scrum and Agile productivity. This is where the 100%-plus productivity occurs not to mention the creative ideas, enjoyment of working, and quality.

Dr Jeffery Liker, author of “Toyota Way,” estimates that only a very small percentage of US Lean adoptions include its core principle, respecting, valuing and engaging the workers. There is a very tricky understanding between Scrum and non-Scrum. If we continue to apply the principles of directed, supervised work we are doomed to Lean and Scrum being another fad, another cover for a continuing use of Scientific Management and its management practices.

Many organizations have not adopted the self-organizing, team-based aspects of Agile. They still are predictive, top-down organizations. Tools that don’t support this function are hard to sell. However, form follows function. If we continue the same predictive manufacturing model, wrapped in Scrum tools, we as software professionals will have a very hard time rising to the increasing demands of our world for creative, sophisticated, quality products.

Scrum without self-organization and empowerment is a death march, just like waterfall, but an iterative, incremental death march without slack.

Also, the blog extols continuous flow. Now, I’m all for continuous delivery. It allows time for competing ideas, exploration, and emergent ideas. However, continuous flow is a Lean manufacturing technique, best formalized by Kanban. It is great for complicated work, such as service tickets, customer complaints, and some bug fixes. Kanban  is a very specific set of techniques from Lean that is applicable when the work is inherently simple. The work also may have been simplified, through standardized techniques, requirements description, or assigned roles. This is complicated work (where more things are known than unknown), not the complex work Scrum is designed for (where more things are unknown than known). Only the most sophisticated Scrum organizations have gotten to this type of work normalization and flow of work on products.

I’ve seen continuous flow touted as a simpler Scrum. It isn’t. It is another process for different types of problems. Waterfall was a simpler process for complex work: its failure rate indicated that it was inappropriate. The same failure rate will occur with Kanban as applied to the complex work of software development.

Jeff Sutherland, myself, and the Scrum community are updating Scrum with “Scrum Guide 2011” on July 21. It contains some significant and subtle changes. These changes build on the core principle of people being the value in organizations. The thought path Microsoft is following continues the old path of people being micro-managed, interchangeable resources.

I’ve often wondered why Microsoft is building tooling around Scrum and doesn’t have either of the authors of Scrum, Jeff or myself, as an adviser. We could help it avoid these mistakes and keep its tools consistent with Scrum. The right process produces the right result (from Lean). Similarly, the right implementation of the right process produces the right result.

Only build tools for things in which you have expertise, not just the experience.



37 thoughts on “Microsoft and Scrum

  1. First, +1 on self organization instead of directed, supervised work.

    Then, I have a question about your sentence “This is complicated work (where more things are known than unknown), not the complex work Scrum is designed for (where more things are unknown than known).”:

    Kanban for knowledge work (as defined by D.Anderson) is a change management approach, designed to be added to existing processes and cause people to get onto the path of Kaizen. Do you really think that when such a change management component is added to an underlying process like Scrum, Scrum would suddenly lose the ability to provide a context in which a team can solve complex problems? Why should continuous flow and solving of complex problems be mutually exclusive?

  2. Pingback: What am I thinking about? People are NOT resources. « On The Job Alliance

  3. Pingback: People are NOT resources. « On The Job Alliance

  4. Thanks for this post. I was always very suspicious regarding “Agile” tools. More especially with ones produced by Major companies … Did you have the opportunity to evaluate RTC developed by IBM? One of my customer use it, including all Scrum terminology but in a full C&C environment … 😉

  5. Great post, very well stated. Interesting why so many organisations still can’t see micromanagement and find it hard to let go, even in the tools. If the tools embrace the problems, bad habits will be even harder to shift. I have to say that there does seem to be a pattern where some of the tools on offer today adopt some processes of Scrum, but seem to engulf them in old fashion mind sets. It might be an idea if there was an independent body which assessed/evaluated scrum tools for a ‘seal of approval’, to discourage neglect and assumption and keep the value of Scrum high in the development environments. It might help breed out instances as mentioned in VS.

  6. Ken – You know that I’ve spent the last 6+ years building and selling Scrum tools to companies adopting Scrum/Agile. It seems to me that MS is building a product to sell it using the Scrum trend, not to enforce specific aspects of Scrum that many/most companies adopting Scrum appear to be missing. In my experience most companies still see Scrum as a silver bullet, quick fix, and minimally invasive because they ignore the parts that force cultural change. They are doing the daily stand-up, but they are assigning work and treating people as fungible resources to be swapped between teams for “efficiency”, etc. It’s disappointing that Scrum’s game-changing principles won’t be a part of MS’s product.

  7. Ken,

    We were discussing this post in a forum and a guy gave a really nice suggestion as workaround.

    Take a look:
    “When I first saw the Agile planning tools in Dev11, my first question was: Can we run it with a “/SCRUM” switch (so to speak) where it corrects the labels from “assigned to” to “owned by”, hides capacity planning/discipline/role, uses “Sprint” vs. “Iteration”, has first-class support for DOD, uses PBI vs. story, etc.”

    IMHO, that solution is relatively easy to develop and it will bring back the TFS to Scrum mindset.

    What do you think about it?

  8. Blogged my impressions on this ( – I’m a little less charitable in my assessment as I’ve seen the pattern of the VSTS team “aping” agile before. While I like Andre’s suggestion for a “/Scrum” switch to change labels, we really should be beyond hacks like this: The point of Process Templates in VSTS is to provide guidance and an un-obstructive UI/UEX for capturing key artifacts like user stories and tasks.

    BTW, anyone else notice how the new Product Backlog and Task Board bear more than a passing resemblance to Urban Turtle?

  9. Just yesterday I passed the PSM I exam. The days before I studied the Scrum guide and became more and more enthusiastic about Scrum. Why? Because I know from my own experience that people tend to be more engaged if given responsibility in a structured setting. I see a lot of people with problems like burnouts leave the working environment because they are unable to use their skills and creativity in a way that suits them. I really think that less directives of management leads to higher quality output because the whole team will be engaged and creative to find a great solution in a highly interactive environment.
    Yes… you can say for sure… I am looking forward to having a first assignment in a Scrum Team!

  10. Andre,

    Would that /SCRUM switch also prevent the tool from keeping tabs on a person’s “available capacity”? Would it also make its measurements less concerned with a micro-management mindset? I think what we see here is a fundamental clash between the vendor’s POV, which is inherently tool-centric, and the agile community’s POV, which, as Ken reminds us is people-centric rather than tool-centric.

  11. I don’t disagree with some of the principle positions you take around group problem solving vs. individual assignment and pull vs. push. I think a lot of it stems from businesses looking to draw lines around the work effort and budget/plan things with finite numbers (even though they are nothing more than guess work, perhaps somewhat educated).

    I wanted to clarify that last paragraph – are you saying that you have never had any involvement in the TFS product planning or just that the vNext is going in a direction that you don’t agree with?

    I see things like the MSF for Agile Development v5 content with your name on it (, a presentation that features you on TFS and Scrum ( and a book you published with MS Press ( a while back. It seems odd that you wouldn’t have had any involvement with product planning.

  12. Hi everyone,

    We’ve been experimenting with several tools (including ad-hoc spreadsheets) and Scrum / “Scrum, but” approaches, and I’ve found something that to me is central to an agile (Scrum or other tool) … most tools lock you in a underlying model, while agile is precisely self organizing to the way of work that best suits a team.

    Let me be more specific through examples from my own experiences (I’m talking here of projects using agile flavors, not Scrum all the time). For a particular project, we wanted the tool to reflect how commitments were honored by the team day by day, while for another (a stabilization project) we wanted to see how fixes progressed along the sprint, while for another we were more worried about monitoring WIP, etc. Each required organizing the taskboard and other artifacts in different ways, so they quickly reflected visually the dimension we were most focused on. The dimension of choice was inherent to the nature of each specific project. Trying to force focus on a dimension on a project of a different nature would be counterproductive.

    In the same way the team decides its own way of working inside the sprint, I think different projects need different tool approaches, and maybe it’s even up to the team to decide the tool approach to use.

    I’ve been thinking lately that a true agile tool should provide for basic functionalities (e.g. functionality for modeling visual taskboards) that every team can adapt to each particular project. Trying to promote an uniform tool for the whole organization may be even counter-agile.

    Of course, these are just musings on the subject … not claiming the truth here.


  13. Thank you for talking about paradise. In big companies micromanaged people are so focused on “classical careers”, that they eventually become zombies. It is hard to turn back alive again 🙂

  14. Pingback: 14 Roundup – 24th July 2011 | 14principles

  15. Mr Schwaber,

    The responsibility of a ScrumMaster has been a challenge. Management could not trust Scrum, their anxiety is reflected upon the expectations put upon ScrumMaster and the Scrum process. Sometimes management uses tools and warp Scrum to fit their previous established project expectations. I think ScrumMaster is more like a change agent. Otherwise, ScrumMaster who is suppose to protect and promote Scrum, ends up doing:
    1. team lead decisions
    2. project manager decisions
    3. become microsoft excel secretary for the team
    4. a communication proxy

    And I think tools like TFS wants to fit right into all management styles

    In actualy fact, Scrum is successful with strong communication between developer team, ScrumMaster and Product Owner.

  16. I think you might be missing the point. The tools in are agnostic to the process template. They can be used with CMMI for example. If a team decides not to focus on the users capacity, then great. Do not put any information in the estimated and completed fields (or get rid of it). The reality is that many teams do want to use this. So the taskboard etc tools are not Scrum only tools.

  17. The problem might not be the tool itself, maybe it’s the ScrumMaster that have problems.
    I once seen a tool called Greenhopper. However, the product owner misused the tool by filling his own estimation of user stories points by summing hours planned per story.
    Once I had a manager who wasn’t contented with the hours remaining field. He asked the TFS administrator to give hours clocked as separate field. Now the team fill in two fields. Then he implemented security where only authorized management level can add product backlog item. When a tool allows flexibility for everything to be done, it’s may not be Scrum anymore.
    Ken has a valid point. But Microsoft is also valid trying to make their product marketable. Microsoft should rename the tool as Agile Application Lifecycle Manager rather than call it ‘Scrum based tooling’.

    My experience you can do Scrum anywhere with simple stationeries:
    1. Whiteboard or Flat Wall Surface
    2. Marker pen
    3. Paper, Sticky or Magnet buttons
    4. Chart roll
    The rest is the extent of human skill to inspect, communicate, collaborate and retrospect

    May I go as bold as saying: If ScrumMaster doesn’t know what he is doing, it doesn’t matter Ken Schwaber himself designed the tool.

  18. The self organizing team is one of the core concepts of Scrum and it makes Scrum really unique between all other methods/frameworks. Personally I am convinced about all the advantages of both teamwork and self organizing high skilled workers. And all management literature from the past decades do tell us the same message:
    1. Most of the work in organizations should be done by teams
    2. The role of management is creating the conditions where a team can evolve into an effective performing unit
    3. Micromanagement is not the way to manage high skilled workers, give them challenges, objectives and some minimal rules yields to much better results.

    But what I as an Agile Coach and Scrum Trainer, see in practice, is that the self organizing team is the most difficult part of Scrum. Many people do not really believe in it, or do not completely understand it, and it’s the most difficult part of scrum to implement. Although the self organizing team is one of the most powerful concepts in Scrum, most organisations do not use it. They implement Scrum because they like the overview of the Scrum board, the control that the backlog gives the frequent deliverables, etc. They rename the Project manager to Scrum master, or even call them Scrum master/project manager

    It would be helpful to clearly distinguish what kind of Scrum is applied. I would suggest using another name for Scrum without self organizing teams. Just to make transparent to all people involved (and committed) what they are doing: Scrum with self organizing teams or without. Someone should come up with a label for the latter approach. Something like AMMM (Agile Micro Management Method) or SWTT (Scrum Without Trust in the Team).

    I do realize that the proposed acronyms suggest I want to judge or blame people who are doing Scrum without self organising teams. But that’s not the case. What I think is the best approach may not fit in another situation. And people are free to lead their organisation in the way they think is best for them.
    But the primary reason I would like to use another name for Scrum without self organizing teams is to make clear what we are talking about. When someone’s stating “we are doing Scrum here” we should know what that really means. Scrum Scrum or a derived kind of Scrum. Transparency. Telling it like it is.

  19. I took my CSM from Ken in 2004 and while i do think it a slippery slope, when developing a tool that is used on the scale of VS/TFS, you have to leave some flexibility, in addition to some core idealogy – that’s what it’s supposed to be about. There is clearly a ‘loophole’ for bad behavior and traditional C&C thinking in the tools, but my hope as a strong advocate of Scrum is that we don’t let the flexibility of the tool “change” the doctrine or tarnish the methodology. Fwiw, i’ve done very large scale “by the book” Scrum projects using tools from Rational – i didnt let the tool get in the way of the right way to run the software development. I’ve also spent the last 7+ years hand stitching tools to get something close to ALM and while we always got something that worked, we never got anything as integrated and efficient as what Microsoft ALM offers.
    PS – Victor, i bought Scrumworks in ~2005 and have followed it’s growth – i could easily find features that make it look “un-Agile” 🙂

    • Kurt – of course, we have un-Agile features left and right because the market demands it. My point was simply that until the people purchasing these tools “get it”, we’ll continue seeing tools that cater to Scrum-but.

  20. Pingback: Ein Todesmarsch - Inspect & Adapt

  21. Pingback: Ein Todesmarsch | ETECTURE Agile-Blog

  22. “Kanban is a very specific set of techniques from Lean that is applicable when the work is inherently simple”. Could be true (not so sure) in a manufacturing context, but not when applied to complex software development as described by David J Anderson. See first comment…

    “The same failure rate will occur with Kanban as applied to the complex work of software development.”
    One can infer that this is your wish… Let’s see how things will develop …

  23. Excellent note Mr. Schwaber. On the other hand, I have noticed that Brian Harry’s views in his blog, on occasions, are not all based on a full understanding of the principles that underlie agile or adaptive development ideas, but I support the critical position that sometimes adopt (, as critical thinking is a necessary meta-principle in agile methods, as I see them. On the subject, if TFS’s default process template does not give me what I need then I customize my own template so that TFS follows the process of the project and not the project follows the template configured by default. In other words, I have noticed that Microsoft designs general products and includes some popular choice by default; in this way they try to cover their target market by offering something for all: Mort, Elvis, and Einstein (

  24. I’ve as a coach seen far too many teams, managers and organisations miss the point of Scrum entirely. They often use various Scrum tools. Such users of tools, who are helped back into old habits and hence lulled into complacency are getting only what they deserve: “Mediocre success”. Only a minority will have the intelligence to appreciate the importance of following Scrum principles…

  25. Penso que se você necessita de uma ferramenta para fazer Scrum, então você não está fazendo o Scrum. Muitas vezes sou questionado sobre qual ferramenta é melhor para usar com Scrum e prontamente respondo, Quadro branco. Só isso deve resolver o seu problema. Não será uma ferramenta que irá fazer o seu processo funcionar e sim as pessoas envolvidas nele. Se você necessita de uma ferramenta para fazer o Scrum funcionar, você não está seguindo os princípios do manifesto ágil.

  26. Hi! This post couldn’t be written any better! Reading this post reminds me of my previous room mate! He always kept talking about this. I will forward this article to him. Fairly certain he will have a good read. Thank you for sharing!

  27. First off I would like to say excellent blog! I had a
    quick question that I’d like to ask if you do not mind. I was curious to find out how you center yourself and clear your thoughts before writing. I’ve had
    a difficult time clearing my thoughts in
    getting my thoughts out there. I do take pleasure in writing however it just seems like the first 10 to
    15 minutes tend to be lost just trying to
    figure out how to begin. Any suggestions or hints?

  28. The only thing I was wondering about with regard to Kanban is that it looks more suited to teams such as my own, where we do some work on existing systems we’ve written, and also create new systems – i.e. where the team is not 100% dedicated to one project. So while you can perhaps employ planning poker and product backlog and refinement, and regular feature reviews and feedback, but the concept of a sprint is too hard to estimate, as you don’t know what other work will come in at the same time.

    Perhaps Kanban is more suitable in this sort of situation?

  29. Pingback: Surprise: Microsoft Is Agile

  30. Pingback: » Подборка полезных статей от 21 марта Блог о проактивном бизнесе

  31. Pingback: The Agile Values in Practice - Agile Socks

  32. Pingback: The Agile Values in Practice – Business 2 Community – Texas Nurse Practitioner News

  33. Pingback: The Agile Values in Practice | Online Sales Guide Tips

Leave a Reply

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

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

Facebook photo

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

Connecting to %s