|
|
-
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.
|
-
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.
|
-
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?
|
-
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.
|
-
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: - It added up all the outstanding hours remaining on linked Tasks and reflected this total on the PBI
- It synced up undone and linked SBI’s to have the same Iteration Path as their PBI “parent”
- 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: 
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. 
And those WIT’s are linked back to that PBI, using a different link type. 
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: - All your Sprint Backlog Tasks are Done
- All your Acceptance Tests have passed
- All your linked Impediments are closed
|
-
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.
|
-
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.
|
-
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.
|
-
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.
|
-
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.
|
-
-
The new bug model in Scrum for Team System 3.0 might look obvious at first, but it's taken a long while getting to where it is. Before I start delving into how the new bug model works, it's worth taking some time to describe what came before it. Almost by coincidence, each of the three major versions of Scrum for Team System have had a different bug model, this represents both an evolution in how teams are becoming more Agile as well as a reflection of how powerful and expressive TFS is becoming as an ALM meta-process platform. NOTE: It's worth noting that although VSTS itself only gets hierarchical work items with 2010, we've always modelled a pseudo hierarchy with our process template. Some people took to it, others didn't. Everybody however understood with the release of Task Board for Team System however, because that visualised the parent - child relations between the work items. Please keep in mind when I'm talking about 2005 and 2008 that there was always a "conceptual" parent child hierarchy even thou this wasn't explicitly enforced or supported by TFS at the time. Version One for TFS 2005 The Version One series was our first attempt at a process template and was purely designed for our own in house use (Conchango having discovered Scrum in about 2003 through consultants still with us today such as Howard van Rooijen and Stuart Preston and of course our ex-CTO lately Global Head of Agile Colin Bird). For Version One, it was decided that developers during the Sprint would either be working on new work (SBI's) or fixing broken existing work (Bug's) - and so it seemed logical to have Bugs as "children" of Product Backlog Items (PBI's) It looked like this: 
And people accepted it readily. Mainly because it mapped to what they were already doing. Testers could raise bugs against PBI's and assign them to developers. If you wanted to raise an "out of Sprint" bug - for example one raised by a customer, you were supposed to create a new PBI in good Scrum fashion, but because the hierarchy was implied and not actual, a lot of people just used the Bugs as they came. It's also worth noting that back in 2005, this was a process template in the true sense of the word, some people used it as was (because it was complete), but many people modified before using it on a real project. Version Two for TFS 2008 By 2008 Conchango was pleasantly surprised by the external take up of the template and was keen to produce something for the forthcoming TFS 2008 - and let's just say that Microsoft was enthusiastic for us to do so too! The Iteration Path was now available for use by 3rd party templates so it felt time to re-address the general implementation of the template. One of the key areas troubling Colin at the time was that the existing bug model wasn't "very Scrum". Experience had shown that it encouraged people to raise bugs "in sprint" instead of talking to each other. So he took the existing model and flipped it on it's head. Taking the Scrum mantra of "bugs are prioritised by the Product Owner along with all other work" to heart he "promoted" bugs to the PBI level and worked out a "Scrum Pattern" for how the team would work on In Sprint bugs. So we went from the model shown above to the following: Which resulted in Backlogs that looked like this: 
So this was great for Product Owners and for bringing into TFS Bug sightings from customers. It also gave projects the much prized single work stream of new features and bug fixes. Finally Scrum for Team System was pure Scrum. But what were you supposed to do if you found a bug in the middle of a sprint? This is where the "Ready for Test" state on the SBI (Sprint Task) was born. This state allowed teams to decide which Sprint Tasks were testable and which were not - and thus "self organise" and trust each other to do the right thing (or put more simply, "Do Scrum"). Teams were meant to "iterate" backwards and forwards between In Progress and Ready for Test on their Sprint Tasks until they were at the required quality to be considered releasable as a potentially shippable increment of code. It looked something like this: 
So this was great for Scrum teams and a nightmare for Scrum-butters. It wasn't perfect however, although I've worked with many teams who really "got" this way of working, where I personally ran into problems with this approach was when the test resource was off shore and more significantly in a different time zone, or in the dreaded "works on my machine" syndrome. Modern software is complex and often difficult to debug, so I felt the need for a "richer payload" during the Sprint - even sometimes just to remind *Myself* of problems that I'd found, so I could reset my context the next day. I was feeling the need for the ability to raise a bug in-sprint, but the agilist in me knew it was wrong. I also knew that adding back in an in-Sprint bug type had the real potential to mess up a team's ability to develop good and productive agile practice if their old fall back of raising a bug rather than working together to complete the PBI was sitting in the corner making beckoning motions. So I started to think... Version Three for TFS 2010 The bug model you see in 3.0 was in fact originally destined for Version 2.3 however it's implementation is far richer in 2010 and so we've focused on that first. You'll see 3.0 come out into production before you see 2.3 released (unless we hear some demand for us to do otherwise) Shortly after the launch of 2.2 was when I started to get fully Test Obsessed and becoming a hard task master about always always always having Acceptance Tests on Backlog Items, especially those utilising User Stories. The payoff for this discipline was amazingly good, and so I began on a quest to add a new Work Item Type to Scrum for Team System - the Acceptance Test. Previously, Backlog Items in Scrum for Team System had a free form plain text field for "Conditions of Acceptance" - which was a nod to Mike Cohn's "Conditions of Satisfaction" which was his attempt to make the term "Acceptance Tests" more palatable to those business types who woke up one morning to find themselves as Product Owners. So technically we had it covered. The problem was, that it was a bit invisible and you couldn't really do anything with it. I wanted something stronger; something I could report on, something I could see and something that I could have red and green flashing lights on to let me know what was going on. Nothing but a WIT was going to cut it. In my mind and on my prototype, In-Sprint Bugs then became "Failures" which was something an Acceptance Test could have, and it was good. (But not released) At about this time I went to PDC 2008 in Los Angeles as a guest presenter with Lori Lamkin and Sunder Raman from Microsoft (there is a video on Channel 9 if you look hard enough) - on Agile Software development - and I saw TFS 2010 for the first time. So from that point it became clear, Product Backlog Items were to be "tested by" Acceptance Tests and Acceptance Tests were to be "failed by" Bugs. Using TFS 2010 named linkages we get the following: 
So why Bug Report? If you've stuck with me this far the answer should hopefully be obvious. In Version One, Bugs were Sprint Backlog level Work, you could assign hours to them and burn them down. In Version Two, they were Product Backlog Level Work, you could story point them, assign Sprint Tasks to them which could then burn down. But in Version Three, they're just Bug Reports - they optimised to let you capture all the information about a Bug, but you can't "do" them, like you used be able to "do" both previous "bug" types, it's for this reason that we now refer to them as "Bug Reports" (even if your copy of Beta 1 says, "Bug" for which I apologise!) I'll explain more on how to actually use the 3.0 QA system in the next post.
|
-
There has been some small amount of confusion around the Scrum for Team System version numbers, especially with the popularity of the 2010 TFS Beta. This short post should help clarify things. | Version | Latest Release | TFS version | Next version | Expected | | 1.x | 1.2 | 2005 | No longer in development. | NA | | 2.x | 2.2 | 2008 | 2.3 | 2010 | | 3.x | 3.0 (Beta 1) | 2010 | 3.0 (Beta 2) | Q4 2009 | Please also note that each version of Scrum for Team System also has it's own specific version of Task Board for Team System.
|
-
To support the release of Beta 1 of Scrum for Team System 3.0 for 2010, this is the first in a series of blog posts that will help you prepare for the release of the template and better plan your adoption strategy. Scrum for Team System 3.0 (for TFS 2010) brings with it many changes, many of which work together to produce what I believe is our best template yet. Improvements however don't come without a cost, and in 3.0 that cost is some added complexity for the simpler projects. This post will attempt to sum up the changes, and some of the drivers behind them, whilst the following posts will go into each area in more detail. So what's changed?- Brand New QA Model
- Multi-team/multi-cadence support
- Better in template support for release planning
- Better in template support for enforcing done
- Support for Lab and Test Manager features (Camano)
- Calculability of state
- New de-scoping system
As always, our philosophy has been to make it easy to do the right thing, whilst being flexible enough to allow people to get the template working in most environments. It does need to be stated however that Scrum for Team System is a Scrum template, not a generic project manager template, or even generically Agile. We think this is a strength. Brand New QA Model The changes here are so extensive that they really do deserve a series of posts of their own. However suffice to say that we took the plans we had for 2.3 and put them on steroids by implementing them with 2010. Multi-team/multi-cadence supportSfTS has always been great for single teams, and for small numbers of multiple teams all working to the same cadence. Where the standard solution started to break was with really massive programmes of work. In the past we've worked with some of our larger clients to adapt our own template, but in 3.0 we decided it was time to "bake in" a system that would enable us to describe a far wider variety of team set-ups and build it into the template itself. In that way all our standard reports and queries will work right out of the box, no matter how complex your project. Better In-Template Release Planning SupportGood release planning is essential to agile project success. Whilst we're also working on some great add-on tools in this area, we thought we should bake some better release planning features into the template as well. They're modest, but very useful. Enforcing DoneOne of the top five Scrum-but failures has to be "not quite getting to Done" at the end of the sprint. We've harnessed the power of TFS 2010 named links and our new and improved Event Service to make this a little easier to enforce. Support for Lab and Test ManagerOur new QA model fits perfectly with the new Lab and Test Manager features so those "no repro" bugs are accessible inside the process template. We feel we've managed to harness the power of this great new tool, whilst still staying true to the principles of Scrum. Thanks to Euan Garden at Microsoft for his help with this one. Calculability of StatePreviously, one of the great trade offs in Work Item state transitions was "how to guide users" vs "allowing for oops states". In 3.0 we've employed a simple rule that allows us to model the "expected legal transitions" but still allows you to fix mistakes. It's going to allow us (or you) to write tools to validate and correct the entire "state machine" of your Work Items. New de-scoping SystemThe old deferral system in 2.x worked, but it was tedious to do, and prone to error as well as misunderstanding. The new way is much cleaner, and focuses around the PBI's rather than the Tasks, where it always should have been.
|
-
Scrum for Team System version 2.2 was recently released. The most significant new project management report is the Velocity Report.  The velocity report tracks the historical "burn rate" for a team in such a manner to allow for truly accurate release planning. Throughout this post I'll use the term "Story Points" as the Unit of velocity, however everything is equally applicable if your team uses Ideal Days instead. What does it show? The Velocity Report gives four essential pieces of information across specific time periods. These time periods may be either the entire project as a whole (to date), or one of the releases of the project to date. If you select the project as a whole (to date) - the report will also indicate which Sprints came from which release. If you have multiple teams defined for your project you may also view the report for all teams or for any combination of your teams (including individual teams) For any given time period selected you can view: - Actual Story Points burned for each of the Sprints
- Average Velocity across this time period
- Average of the three sprints across this time period with the lowest velocity
- Average of the three sprints across this time period with the highest velocity
How do I use it? The most common use for Velocity in Agile Project is in Release Planning. Release planning is simply the act of determining what functionality you're going to be able to deliver in what time frame across your project. Obviously you want this data to be as accurate as possible. The greatest accuracy is gained by basing this Velocity figure on observable historical data. However, human beings are imperfect, if you simply take a single figure for your Velocity your release planning is likely to be in-accurate. Using the three averages from the Velocity Report will produce far more accurate results. Think first of your backlog in the order in which it will be built (which should be pretty normal for most Scrum teams) - then cumulatively add up the estimates against each of your PBI's. Then take each of the average scores and multiply them across the number of Sprints you have remaining in your project or release. This will give you your best, average and worst case scores for the amount of PBI's you can burn down across the scope of your project or release. Think of these three scores as dividing up the PBI's in your Product Backlog into 4 zones. Zone A) - This is the zone above your lowest average velocity. Zone B) - This is the zone between your lowest average velocity and your overall average velocity Zone C) - This is the area between your overall average velocity and your highest average velocity Zone D) - This is the area below your highest average velocity Then you can evaluate your release plan using the following system. PBI's in Zone (A) you're almost guaranteed to get. PBI's in Zone (B) you're very likely to get. PBI's in Zone (C) you'll conceivably get, but it's not likely. PBI's in Zone (D) you're guaranteed not to get. Match those predictions with what you know about what you need for this release or the project as a whole. Ensure that the PBI's in Zone (C) are only in the "nice to have category" and that you're not expecting to get anything in Zone (D) - this really is the Zone of things we're not going to get. Re-prioritise your PBI's until the essential components of your release is solely in Zone (A) and Zone (B).
|
|
|
|