Welcome to EMC Consulting Blogs Sign in | Join | Help

Simon Bennett's Blog

  • Nobody can do Agile

    Let's be clear on one point.

    You can't do Agile.

    You can only be Agile.

    What causes some confusion I think is that in order to be Agile, you often need to do some of the things you're currently doing now differently.

    But if you really want to succeed at being or becoming Agile, you really need to first conquer how you're thinking.

    Agile Is Culture, Not Process

    Before you learn anything else about Agile, you should take this concept on board.

    Because it frames absolutely everything else that you learn and do after that point.

    Many Agile coaches and trainers think that the majority of their students infer this fact based on the common practice among good Agile courses of starting with the Values and Principles of the Agile Manifesto.

    But in my experience, this isn't true enough of the time.

    So I feel it's time to start saying it explicitly:

    Agile is Culture, Not Process. This is what the Agile Manifesto is trying to tell you. This is not a process you can simply adopt. It's potentially a new way of life.

    When faced with something genuinely novel in a familiar setting, the majority of busy people have difficulty relating the abstract to the concrete. This is doubly so if they are making the assumption that what they're seeing is not in fact genuinely novel, but just yet another process with weird new words for things they've been doing for years.

    "So this year we're calling our requirements User Stories and Milestones are now called Sprints and there are a lot more of them"

    The second problem with implying culture solely from teaching the Manifesto is that most people have been subjected to around 10-15 years of Corporate and Management Consulting rhetoric which has resulted in the words Value, Principle and Vision having in many cases lost all meaning.

    So in a lot of these cases, once they hear the word "Values", some folks tune out of the Agile Manifesto stuff...

    ...then only tune in when the instructor starts talking about specific practices that they can concretely relate to their job.

    Why does this matter?

    Starting with the concept that Agile is not a process, but a culture allows for the possibility of being Agile but doing things that are "the same" or "similar" to the way in which things are done now.

    Mental Models

    The mental model of "Agile is a process"  drives people towards asking questions like:
    "How does Agile handle this specific thing [that is a pre-existing concept present in my culture] differently to the way my existing process does?"
    ...and if the answer does not appear sufficiently obviously different to them, then they reject Agile as a whole because it's "no different" and thus clearly snake oil.

    The concept of Agile as a process leads people to believe that if Agile is to create "better" results, then the mechanics must all be different. And if they are not convinced that the mechanics are in fact different, they then reject the premise that the results could be different.

    Finally, thinking of Agile as a process leads to the 'pick and choose' mentality of
    "We'll try daily stand-ups and see if that doubles productivity"
    or the pick and reject mentality of:
    "We can't do Agile because automated testing is impossible"

    Situational Coaching

    So I was talking about this just the other day at a social gathering and an acquaintance (who is currently involved in an Agile adoption) said to me:
    That's what we're doing. We're trying to change people's behaviour. People expect to have a process, to be told exactly what to do in any situation.  But instead, we're saying 'you can decide for yourself what to do and these are the principles that you should use to determine the best course of action' But it's not really working. They're just waiting for instructions. Help!

    So that probably came out differently than how it was meant - but obviously teaching people the Agile principles and then saying "you decide" is not going to work in the majority of cases, which is why in my team at EMC, we use what we call the "Situational Coaching Model" (which is based on the Situational Leadership Model)

    In a nutshell, the Situational Coaching Model sees your Agile Coach taking your team, project, programme or even organisation on a journey through Directing, Guiding, Supporting and finally to Delegating.

    If you've not read the referenced article, one of the key points is that in the first two phases, the Coach decides how the team approaches the situation. The rationale behind this seemingly un-Agile approach is that in the early stages of adoption it's only the coach who's living and breathing the manifesto, and whose job is not on the line when they cross the corporate culture police.

    The beauty of the model is however if the team already lives the Manifesto, then it's easy to move through the stages quickly. (I have horribly oversimplified my explanation of this approach)

    I think as a community we're sometimes not correctly setting expectations as to just how long it can take teams to move out of the first two stages.  It's just not something you can set to a timetable.

    Being vs Doing

    One of the aspects of "being" as opposed to "doing" is that ultimately every individual decides for themselves. Your boss can make you "do" something. They can't however make you "be" something. (Except maybe miserable if they do a lot of the first thing)

    It's the attitude that each individual brings to the daily stand-up that matters exponentially more than the precision with which they follow the process of answering those three questions and taking up exactly 15 minutes a day on it.

    If you don't internalise the culture / process distinction - you'll never leave the first two phases.

    This is the leading root cause behind Agile rollouts that begin to "come unstuck" once all the Coaches and Trainers leave. The culture never changed.

    If Agile isn't a process, then why is there so much emphasis on how to do things differently?

    There are several answers to this question - some reasonable, some harsh.

    Reasonably speaking, once you start to believe and value different things - you look for ways in which to support your new beliefs and values. The central tenant of quality, quality, quality in the Agile Manifesto Principles drove people to find better ways to develop and test software. The emphasis on working software as a measure of progress led to developing software in vertical slices, which in turn led to Continuous Integration in XP and resulting in the burn down charts used in Scrum.

    These techniques are mostly all awesome - and generally useful too even if you're not Agile, which causes confusion if you believe Agile is a process.

    But understand, regardless of their subsequent general utility these techniques were born of the Agile culture; the desire for individual mastery, the desire to enjoy work for a sense of camaraderie, pride & craftsmanship.

    The harsh answer is however that the emphasis on processes and techniques is potentially a failing of those trying to teach you Agile - either knowingly or unknowingly.

    The knowing kind are the worst - these are the people who do know that Agile is culture, but assume you don't want a culture change and so tell you it's a process because they want to take your money.

    The unknowing kind may very well be experts in other fields, but are genuinely ignorant of the true nature of Agile themselves. Perhaps they're enthusiastic beginners, or perhaps they were led astray by one of the "knowing kind".

    In either case, are these the people you want guiding your Agile adoption?

    Or to be more accurate, your Agile transition, because if you've read this far, I hope I've convinced you that you can't really adopt Agile, you can only transition your culture towards it.

  • Lo-Fi for the Flow Guy

    Recently I was doing some pair Kanban Coaching with Karl Scotland, and as is not uncommon during these types of engagements, we got out of the classroom and “took a tour of the Gemba”.

    Whilst the tremendous value that an accurate Kanban board can add to the effectiveness of such a coaching exercise should probably be the topic of another blog post, on this particular occasion another aspect jumped out at me; and that was the raw power of the lo-fi solution.

    There were multiple teams, and each team had their own Kanban board. All were functional, none were fancy. They had been made out of what was to hand, whiteboards, envelopes, post-it notes etc.

    As we moved from board to board we made comments and asked questions, and in several cases, working with the teams we immediately made tweaks and improvements to issues they were facing. And by immediately – I mean we did it then and there.  Limits were changed with the rub of thumb and the swish of a marker, the use and meaning of “blocked” stickers was changed in an instant, batches were made, unmade and sized, columns were added and removed. The changes were tangible and immediate. Changes that worked were kept, those that didn’t were so low cost to make it just didn’t matter.  The sheer absence of friction created its own momentum and spoke directly to the hacker and tweaker that lurks inside everybody passionate about creating great software solutions.

    Whilst seeking process flow, each of us fell naturally and happily into a state of personal flow.

    At the end of the tour each board and team was the better for it.  The level of understanding had risen markedly – as the team now felt the board. The board also described the work better by showing the actual current state & shape of flow as the team understood it (and that was without generating even a single CFD)

    All this was done without permission, the need for a licence, admin access or even a thought to how this might “effect historical data”

    There are some pretty decent Agile & Lean tools out there these days, but for sheer speed and humanity of operation, the lo-fi approach has some serious advantages which I think tend to get overlooked far too often.

    If you and your team have lost that flowing feeling, it might be time to go old school for a while.

  • Does your backlog focus on “The Real Work”

    Say what you like about the iPad, but it’s got people talking, and thinking.

    The effect on the world, to me, is almost more interesting than the device itself.

    Whilst reading this well considered piece, I was immediately struck by the following statement (emphasis mine)

    The Real Work is not formatting the margins, installing the printer driver, uploading the document, finishing the PowerPoint slides, running the software update or reinstalling the OS.

    The Real Work is teaching the child, healing the patient, selling the house, logging the road defects, fixing the car at the roadside, capturing the table's order, designing the house and organising the party.

    Fraser, whether intentionally or not, has spoken about the very heart of Agile itself, and at the same time described why so many individuals and organisations fail time and time again to “get it”.

    The Product Backlog (just to use a commonly understood artefact) is not a requirements specification that speaks of formatting the margins; the Product Backlog is a list of all the “Real Work” that needs doing, and is yet to be done.

    What does your backlog focus on?

  • Descoping work in Scrum for Team System Version 3.0

    It’s always been possible to descope work in the Scrum for Team System template. But the method employed in Version 2.2 whilst functional, was quite fiddly, overly manual and not very “Scrummy”.

    When building 3.0 we took the opportunity to revamp the way in which it worked and better utilise the power of the Event Service (something you can see throughout the template).

    Deliberately descoping work mid-Sprint is a very useful practice for Scrum Teams, especially when they first start out on a project, so we felt it was important to make this feel easier and more natural to do.

    The headline change is that you now descope Product Backlog Items (PBI) rather than defer individual Sprint Tasks as was previously the case. The second major change is that we’ve made it much easier to rescope work.

    Descoping PBI’s is a more natural flow for a Scrum team – and more accurately models what should be happening at a project level. Remember that good Scrum teams will always descope work well ahead of Sprint Review, descoping (or rather dropping) work the day before Sprint Review is missing the point entirely.

    So this is how it works:

    Some time during the Sprint, the Scrum Team comes to the realisation that they’re “not going to make it” – there could be any number of reasons for this, one or more team members could have fallen ill (Bill for example), some of the estimates may have turned out to be severely incorrect or there may simply be some other impediment which cannot be resolved in time to allow the team to deliver on its previously committed Sprint goal.

    The fact that “we’re not going to make it” should be clear from looking at the Sprint Burn Down chart (remember that the Sprint Burn down is for the team to use to track their own progress). Once the team discovers this fact, the next step is to inform the Product Owner (if they don’t already know) – and to have a discussion about what can be delivered in this Sprint. (Given what we now know)

    The discussion of what can be delivered this Sprint will however almost invariably lead to a discovery of previously committed-to work that can no longer be delivered this Sprint. This is the work that we need to descope. So how do we do it?

    Ideally you’ve been limiting your Work In Progress and working in priority order down your Sprint Backlog. If this is the case then it’s more than likely that the stuff the PO agrees that you no longer need deliver this Sprint (because it’s a lower priority), hasn’t been started (because you’ve been limiting WIP) – see how all this stuff fits together?

    In this case, fire up Visual Studio 2010 and bask in its glory; then go to Team Explorer and find the Product Backlog Item(s) that you are wanting to descope and set their status from “Not Started” to “Descoped” – and then save them straight away.

    Saving the work item will kick off our Event Service which will then set the status of all the linked and “Not Started” Sprint Backlog Tasks to “Descoped” as well.

    Sprint Tasks that are set to “descoped” don’t count against your work remaining for the sprint – and thus allow you to see whether your descoping effort is going to mean you’ll be able to deliver on your new commitment. Those PBI’s and SBT’s are still attached to the same point in your Planning Scope, but they no longer count against work remaining in any of the reports.

    But what if Bill gets better and then puts in some overtime?

    So this is one of the reasons we leave the Iteration Path / Planning Scope alone. You want to keep that PBI in your Sprint Backlog, because it represents part of your original commitment. That’s important data to take into your Sprint Review and Retrospective to help you improve your estimation and relationship with the business. The point of descoping PBI’s is not to hide the work. It’s for no other reason than to mark the PBI as something that’s not part of the “new commitment” (but was part of the old one) – and more importantly, by association to take the planned Sprint Tasks out of the work remaining in the burn down.

    Never forget that the goal of Scrum is transparency, it’s not about making events look bad or good, it’s about representing them as they truly are.

    Rescoping

    If it all starts to “come together again” and you realise as a team that you “descoped prematurely” – then there is no problem. You can simply rescope the PBI by changing its status from “Descoped” to “Not Started” and once again our friend the Event Service will do the honours for the linked Sprint Tasks, setting them all back to “Not Started” as well. Make sure however, that you actually finish all the PBI’s that were not descoped first. All the way to Done.

    Don’t rescope PBI’s because you “feel” that you might be able to do them after all. Finish the other PBI’s first, then rescope (and then send me a postcard)

    This is basically the same procedure that you’d follow in the far more likely case that the PBI stays out of scope for the entire sprint. In this case highlight at Sprint Review the items committed to, and those completed and briefly and objectively discuss the descope moment and the reasons for it. It’s likely that you’ll want to spend a good chunk of your Retrospective on the reasons behind why descoping was necessary.

    Our recommendation is to leave the Planning Scope of the PBI alone until after Sprint Review. After Sprint Review, push the PBI “up” the Planning Scope, typically to the Work Stream or Release Level, and then set it back to “Not Started”, effectively putting it back in the Backlog for reprioritisation and scheduling by the Product Owner (the fact that it was once planned and then descoped is stored in the history). If you’re the ScrumMaster, resist the temptation to simply roll it over to the next Sprint. That’s not your call.

    When you do allocate it back down to Team in the Planning Scope; all the previously planned Sprint Backlog Tasks will come with it, again thanks to our friend the Event Service.

    If you forget to rescope PBI’s they can sometime get lost – which is why we have added a “Descoped PBI’s” WIQL query, so that you can keep your project in order and not lose work “through the cracks”. Check it on occasion.

    A final note on half started PBI’s

    In some cases you’ll need to descope a PBI that you’ve already started. In this case you’ll likely have a “spread” of Sprint Tasks, some of which are “Not Started”, some of which are “In Progress” and some of which are “Done”.

    Obviously the Tasks which are “Done” – don’t really matter. We’ve done these and we can never get that time back. The Event Service simply leaves these tasks alone. Similar deal with the “Not Started” work. We’ve agree with our PO that we’re not going to deliver this PBI this Sprint, so the Event Service assumes that all these tasks will also be descoped and sets their status accordingly.

    That leaves the “In Progress” work. The Event Service will just leave this alone; this means that these Tasks will stay “In Progress” even though the PBI itself has been descoped. This “In Progress” work will still count against your work remaining target in your Sprint Burn Down chart until you either finish the tasks, or descope each of them manually.

    Remember however that when the PBI is rescoped, all the descoped tasks will go back to “Not Started” – regardless of what state they “came” from.

  • The TFS 2010 Product Backlog Ecosystem

    In Scrum for Team System 2.x Product Backlog Items (PBI’s) lived a simple life. They had an iteration path, an area path and were linked to Sprint Backlog Items (SBI’s). Confusingly, the more common terminology for SBI’s amongst non TFS users is Sprint Backlog Tasks – or SBT’s – which is why we’ve adopted this terminology for our Version 3.0 template for Visual Studio 2010.

    To make life easier for people our Event Service did three things to the PBI:

    1. It added up all the outstanding hours remaining on linked Tasks and reflected this total on the PBI
    2. It synced up undone and linked SBI’s to have the same Iteration Path as their PBI “parent”
    3. It marked the PBI as done once all the Sprint Tasks linked to it also became done

    But that was about it, and it looked like this:

    image

    The named linkages in TFS 2010 have enabled us to produce a far richer template. In this post I want to focus on the changes not to the PBI Work Item Type (WIT) itself, but rather the ecosystem it now lives in.

    PBI’s are now linked bi-directionally to three WIT’s – Sprint Backlog Tasks, Acceptance Tests and Impediments.

    image

    And those WIT’s are linked back to that PBI, using a different link type.

    image

    If the reason for this isn’t clear at first, it will become so over the course of the next few posts.

    The key thing to understand here is that we now leverage the Event Service and other TFS 2010 features to help you enforce Done on your projects (Why is that important? It’s a crucial part of successful Scrum, and one of Jeff Sutherland’s pillars of Hyper productive Scrum)

    In 2.2/2008 a PBI was marked as Done when all the Sprint Tasks linked to it became Done. The hours remaining would also be zeroed out, because the Event Service also ensured that when a Sprint Task became Done, the hours were zeroed out. Handy.

    This generally worked well, but wasn’t terribly “strict”, and some teams got themselves all tied into knots because they’d finish all their sprint tasks before they really were finished building the PBI.

    In 3.0/2010 a PBI can only become Done once:

    1. All your Sprint Backlog Tasks are Done
    2. All your Acceptance Tests have passed
    3. All your linked Impediments are closed
  • Scrum in the Enterprise with Visual Studio 2010

    Next week I’m speaking on Scrum in the Enterprise and Process Customisation with Microsoft Visual Studio 2010 at PDC 2009 in Los Angeles.

    There is far more to Scrum for Team System Version 3.0 than I can possibly cover in the allotted time so I’m supporting both the presentation as well as our Beta 2 launch with a series of blog posts.

    To make this information easy to find, I’ll keep this post updated with links to the other relevant posts so that it will serve as a central repository.

    If you’re wanting a quick overview of our 3.0 template then the best place to start is with 3.0 from 30 000 feet.

    If you’re a user of one of our previous Scrum template for TFS, then I’d suggest you take a look at the Three Ages of Scrum for Team System Bugs, which is essential reading if you’re moving from one template to another.

    Named linkages makes a big change to how expressive a template can be. The TFS 2010 Product Backlog Ecosystem explains the context in which Product Backlog Items now live.

  • The philosophy of Kanban is Kryptonite to Scrum

    As awareness of Kanban grows, people are naturally wanting to learn more about it; especially if they’ve tried Scrum and found it challenging or failed to reap any perceivable benefits from it.

    At first glance, many people see the basic difference between Scrum & Kanban being that one system has time boxes, and the other does not.

    Another common first impression is that Kanban does away with estimating.

    And so teams that have struggled with either delivering in time boxes or estimation find these aspects attractive and look to incorporate these into their Scrum projects. Yay! No more Sprint planning!

    But to me neither of those impressions really grasps the fundamental difference, and I think many Kanban practitioners might agree with me. (Chime in guys, I know you’re out there)

    To my mind there is a fundamental difference in philosophy between the two approaches.

    As referenced in my previous post Purist is a dirty word, many people miss the point of Scrum. They mistake the artefacts, roles and rituals for Scrum – and in the process lose the juice. Kanban enthusiasts often point to these roles, rituals and artefacts as flaws in what some of them see as an overly mechanical and prescriptive process.

    But this isn’t the difference either.

    The fundamental difference as I see it, is that Scrum is a disruptive and amplifying system. It turns your project up to 11, and highlights the flaws in the way you do everything. These flaws surface as impediments and it’s then the ScrumMaster’s role to remove these impediments; this is where Scrum gets its power to improve, and why the ScrumMaster is such a challenging and difficult role if taken seriously.

    Take the philosophy of Scrum far enough and you’ll improve the entire ability of your organisation to solve complex problems in record time.

    Kanban on the other hand is a gentler more forgiving system. Especially to start with. You map and measure your existing process, make it visible & then begin to limit work-in-progress and track cycle time. Its proponents say that this is the less disruptive more pragmatic approach. They’re quite possibly right, depending on your exact definition of pragmatic. (Pragmatism is a philosophical movement that claims that an ideology or proposition is true if it works satisfactorily)

    It’s not the purpose of this post to discuss which of these two approaches is better (in fact I think they each have circumstances to which they’re ideally suited – but more on that later)

    My purpose here is to highlight the danger in mixing the philosophy of Kanban with the practice of Scrum.

    If you’re going to use Scrum, but ignore or hide the impediments, (or even not raise them in the first place) then you are asking for a world of pain, and a lack of progress. This is what Ken Schwaber and Martin Fowler are talking about when they speak of flaccid Scrum. (at least from a technical debt perspective)

    Both Scrum and Kanban prize transparency; but they handle it in different ways – and Scrum builds-in an explicit call to action, which needs to be answered for Scrum to succeed.

    Kanban allows for you and your team to simply “accept” impediments, and measure their effect.

    Understanding the difference is crucial, and mixing the two can be fatal.

    Please don’t read this as an anti-Kanban rant, it’s not.

    And, please don’t read this as a call to “keep Scrum pure” – to not adopt Kanban popularised practices such as limiting work in progress. Limiting WIP has long been a standard working practice among all the best Scrum teams I’ve ever worked with.

    It’s a call to understand that neither of these systems are “methods” as much as they are philosophies. I’m currently of the mind that neither is right or wrong, but rather each has its place and the real challenge is figuring out what’s appropriate when. If you’re doing Scrum well right now, and truly getting no benefit, then maybe you are better off going to Kanban because in all likelihood your project is potentially not as complex as you think it is. Flow and predictability as well as end to end to visibility are probably going to give you more benefit.

    On the other hand, if you really are dancing on the bleeding edge then I imagine you’ll come to depend on Scrum.

    To close: The philosophy of Kanban if applied to the practice of Scrum truly is like Kryptonite. That Scrum project will weaken as long as the philosophy is nearby.

    Take it away and that project will regain strength.

    If you cannot bear to do that then embrace your Kanban spirit AND the Kanban practices and stop calling yourself a Scrum project.

  • Purist is a dirty word

    Something strange happened in the last few years. Purist became a dirty word. And "Scrum Purist" came to be the dirtiest version of all. I run into a lot of folks who proudly boast that they're not "one of those crazy Scrum Purists" - that instead they're pragmatic, down to earth and have simply "used the parts of Scrum that work" and ditched the crazier parts. They often then point to a poor ostracised individual sitting alone in the corner and say:
    "He said we shouldn't show uncompleted work in the Sprint Review. But that's just not feasible. We'd look like we were behind schedule if we did that!"
    So, for the crime of asking a team to stick to the rules of their adopted methodology, this poor unfortunate has been branded a zealot. Regardless of how you've reacted to the post so far, the situation described above is not as simple as it might first seem. Because not all Scrum Purists are created equal. The unhelpful Purist is the guy who has learnt the rulebook. Perhaps he carries around a copy of the "Scrum Guide" with him, or has an original copy of Ken's book in his back pocket. He's the one that wants you to do Scrum for the sake of Scrum, and figures that if you do, then magic will fall out the sides. These are the people that give Scrum a bad name. I don't call them purists, I call them bureaucrats. There is however another kind of purist; this is the person who truly understands Scrum for what it is. This is the person that understands that Scrum is not really about roles, meetings and artefacts. Scrum is a complex adaptive system where each of the simple constraints has a place and a purpose; working with each of the others to subtly bring order to chaos. The best coaches & trainers have a background in complexity science and can understand and guide this process effectively. Sometimes in ways that may seem counter-intuitive. These people are not purists. These people are the genuine article. Don't confuse them with the would be bureaucrats who are just mindlessly enforcing the rules without understanding why the rules are there in the first place. Both kinds of person may seemingly act like a purist at any given moment in time by insisting that you follow a rule that you don't understand. But only one of these people knows why. The dictionary describes a purist as:
    A person who insists on absolute adherence to traditional rules or structures
    And based on that, I would say that yes, purist is a dirty word and rightly applies to the Scrum bureaucrats. But if you've ever met or worked with the genuine article, then you know that they're about as far away from the dictionary definition of purist as you can possibly get.
  • Product Owner Panel

    On Tuesday the 20th of October I'm chairing a panel on Product Owner best practices at the Scrum Gathering in Munich. I'd like to introduce my panel members. I've tried to balance out the consultant and authors with some people who are working with Scrum and Product Ownership issues on a daily basis in a variety of circumstances.

    So (apart from me) who is on the panel?

    Harvey Wheaton

    Harvey arrived at Electronic Arts in 2003 to discover a wildly Agile environment.  He says that his Scrum enlightenment came after about a year spent struggling to understand the organic, creative development environment and seeing the absolute need to focus on working software and iterative development.  In September 2008, Harvey moved on to start up a new games studio in Guildford (near London) – Supermassive  Games, an independent studio working on a multiple, publisher-funded Playstation3 exclusive titles.  The studio has put Scrum at the heart of its culture and has grown rapidly to a team of 55 people working on four products for launch in early 2010.

    Roman Pichler

    Roman is as an independent consultant and product owner expert. His new book, Agile Product Management with Scrum: Creating Products that Customers Love, is the product owner's essential guide to developing successful products with Scrum. Roman has more than eight years experience in helping companies transition to agile & five years experience in teaching and coaching Scrum product owners.

    Nadja Fischer

    Nadja is a Product Manager at Agfa HealthCare GmbH where she is responsibie for creating and maintaing the product backlog a Scrum team building an international patient administration system managing 43 sites, 70.000 users & 20,000 beds!

    Nadja’s team have been doing Scrum for 18 months and are the first team in Agfa to adopt Scrum, whilst the rest of her company still works under a waterfall.

    To make matters even more difficult, Nadja's team members are distributed across multiple sites in France and Germany. Despite their distribution they've found ways to successfully work well together as a single team.

    Sven-Ole Bude
    For the last seven years Sven has been a product manager for a variety of publishing solution products at ppi Media. He came in contact with Scrum in late 2007 and as a product owner he transferred a mission critical project from traditional product development to Scrum. He was part of the company’s Agile enterprise transition crew and coached several teams. He is about to start as product owner for an entirely new team this November.

    William Water

    William is a product owner working in a Scrum Team for Educator.

    We'll be taking questions from the audience, so start thinking about what you might like to ask about, the focus is more on best practice and how to integrate with the business, rather than on "how too's" such as Release planning - all of which are covered excellently in other conference sessions.

    Questions?

    If you have any questions about the panel, please come and look for me beforehand, at the very least I'm sure to be at the reception on Monday Night sponsored by our good friends at VersionOne.

  • Prisoner's Dilemma @ the Scrum Gathering Munich

    I'm at the Scrum Gathering in Munich this week.

    On Monday the 19th, I'm re-running my session on Agile Contracting called "The Prisoner's Dilemma: Applying Game Theory to Agile Contracting".


    For those of you who missed this session at Agile 2009 I propose that the larger issue with Agile Contracts is not that we don’t know how to write them.

    After all we know how to deliver Agile projects, so a contract can simply describe that process.

    The problem is with making an Agile Contract commercially competitive; against suppliers who are offering the promise of delivering the perfectly predicted dream.

    This is a prisoners dilemma, with organisations driving themselves towards a sub optimal solution.
    Through game theory I guide the group to explore ways in which to improve the appeal of the agile offering.

    Later this year and into 2010 I'll be publishing paper(s) in support of the ideas I cover in this session as well as doing a partner session which focuses more on purchasing / procurement side of the agile contracting equation, directly addressing risk and how people can see the value in having options. I'm very happy to be able to combine both Game Theory & Agile. Next stop is User Experience (where I still don't see the problem)

    Speaking of risk, my friend and colleague Mark Summers  is also speaking at the Munich Scrum Gathering this week with a brand new presentation specifically on managing risk with Scrum. The two sessions dove tail nicely into each other.

    Lastly there is also a session specifically covering "Ten Agile Contracting" forms by Peter Stevens.

Powered by Community Server (Personal Edition), by Telligent Systems