Definition of Done on Stories

If the stories are assigned to individuals, how can the DOD's be team agreements?

Doesn’t the team’s work have to be integrated into a potentially releasable increment each Sprint, to which a Definition of Done must apply?

The team in question is being asked to provide engineering solutions to operational bottlenecks. We don't have enough resources on the operational side, so we're writing automation to fix that. That turned into a bunch of gathering and requesting information stories. So, there's no actual increment to be delivered for quite some time while we track down all these bits of information that are even needed before we can start automating... Even when we do begin automating, it's not going to be increment driven, and I have NO idea how to take projects like this and make them increment driven. Half the scrum teams are infrastructure, so they're installing literally T1 lines to buildings, or re-structuring a active directory forest.

A lot of the work would normally be handled under waterfall, and it's being forced into scrum. So, I'm doing the best I can, but I really am lost on how to drive that.

The Definition of Done is supposed to apply to the potentially releasable increment of work produced by in the Sprint.  It isn't expected to be applied at the individual story level.  To determine completion of a story, Acceptance Criteria can be used.  These will vary from story to story which sounds extremely close to what you say you are doing.  If all of the stories you are pulling into a Sprint are being done in order to accomplish a Sprint Goal it might be easier for people to understand that the Definition of Done applies to the Sprint Goal instead of individual stories. Then explain to them that the combination of all the stories should create a potentially releasable increment of the product or potentially releasable combination of code changes if that is easier for them to understand. 

So, there's no actual increment to be delivered for quite some time while we track down all these bits of information that are even needed before we can start automating

This indicates a Product Backlog that is not ready and needs significant refinement.  Is the Product Owner not doing the vetting of the problems correctly before taking them to the team?  Sure, there will be normally be additional questions that arise after the actual work begins but a significant portion of them should be able to be discovered before work begins. 

Even when we do begin automating, it's not going to be increment driven,

Why not?  And if so, why are you being forced to do Scrum?  What is driving the decision that Scrum is the best option?

About the waterfall vs Scrum thing.  Scrum does not work for all things.  From the Guide

Scrum is a framework for developing, delivering, and sustaining complex products. 

Scrum is a process framework that has been used to manage work on complex products since the early 1990s

I have heard interviews with Ken Schwaber and Jeff Sutherland where they will state Scrum works best where the problems are complex and the requirements change frequently.  My opinion is that if the work is somewhat routine and the requirements are pretty solid you are actually making things more difficult by using Scrum, which is actually wasteful. 

This indicates a Product Backlog that is not ready and needs significant refinement.  Is the Product Owner not doing the vetting of the problems correctly before taking them to the team?  Sure, there will be normally be additional questions that arise after the actual work begins but a significant portion of them should be able to be discovered before work begins. 

We don't have product owners, we have technical leads, and they're not at all familiar with what the teams is going to be working on, just the technical side of things, it's up to the team to reach out and gather that data from the business / customers / vendors.

Why not?  And if so, why are you being forced to do Scrum?  What is driving the decision that Scrum is the best option?

About the waterfall vs Scrum thing.  Scrum does not work for all things.  From the Guide

Because our VP likes agile and thinks it would be great to get the benefits of agile, despite the fact that our org is not even remotely agile... We have no product owners, I am the sole scrum master divided across atm 10 teams. We have 4 managers for all 10 teams, and 1 director. 

They hired me because managers had previously worked in scrum organizations and wanted to try and implement it here, and tasked me with basically trying to transform them, something as a scrum master with a fresh CSM and only 6 months of prior experience as a tester / scrum master, I was woefully unequipped to do. They needed an Agile Coach, and did I mention we're broke and can't afford to pay people or even hire more?

I have heard interviews with Ken Schwaber and Jeff Sutherland where they will state Scrum works best where the problems are complex and the requirements change frequently.  My opinion is that if the work is somewhat routine and the requirements are pretty solid you are actually making things more difficult by using Scrum, which is actually wasteful. 

That has been the complaint of the engineering teams since I got here. They think they're being unnecessarily confined and required to produce metrics that don't make any sense, and I having no choice but to try and justify my reason for being here, have had to be creative about arguing for scrum. Although I've made it clear our issues are not at the team level, they're at the organizational level, and my director is aware of that and is still choosing to "make it work".

We are just now giving one team the ability to try other methodologies and they're asking me to simply learn with them, so this will be a great opportunity for me to get more experience, but all they want to do is kanban / scrum, where they have a 2 week cadence, less meetings, less documentation, and still no product vision or guidance. 

As a company our main issue is that our Scope, Cost, Time are all fixed. Imo REGARDLESS of what methodology or metric we try to drive, we will fail, because those constraints are unrealistic. We have 65 projects that must be completed before the end of the year, not including regular operations / break fix, AND carry over from last year. Some of which have constraints outside of our org, and not all of those projects are even ours, a good deal of them are outside our org and we literally cannot say no to them. 

Our VP is basically just saying, I don't understand why I can't get that many projects done when we have more engineers than projects, and he's been unable to understand that projects with no vision require a LOT of research and setup time, not to mention the ITIL processes that weigh down the scrum teams, AND the built in delays due to outside orgs having 14 day turn arounds...

Honestly, I have no idea what to do at this point other than to just try and preach the scrum guide, so far my Lunch and Learn sessions have been very underwhelming, the majority of the engineers don't even show up, the moral of the engineers is that this is all a joke and they just want to get the work done.

I've boiled up all the issues the scrum teams are having, the Director is aware, it's just the VP that doesn't get it. I'm being told to "make it work", so I'm just doing my best.

Wow, you have a real struggle ahead of you.  I realize this is a scrum.org forum but I'm going to suggest that you focus on agile rather than Scrum.  Since your "VP likes agile and thinks it would be great to get the benefits of agile," then work on giving him agile.  Coach empiricism and help adapt process/work to utilize that model.  A very simplified explanation of the core of empiricism is transparency of information, inspect all known information, adapt to what is best based on that information. A little on each part.

Transparency - Everyone inside and outside of the team doing the work should be have access to any information about the actual work being done.  Just as the engineering team is willing to let anyone know what they are doing and why, the external individuals should do the same.  Because often the information from the external individuals will become pertinent to the engineering staff and used to adapt. No one should assume that anyone else knows the information that they do or try to determine if their information is relevant to anyone.  Share everything and let the individuals determine if it is relevant.

Inspect - All information available should be constantly inspected. Another way of viewing that is that everyone should be looking for any new information that could impact the work they are doing.  Any impact identified should be raised to the team for discussion.

Adapt - All decisions should be made based on the information you have now. Do not try to predict what might happen in the future or what could possibly needed/requested by someone at some point in time.  Make your decisions now based on what you know.  As transparency provides new information and inspection determines a possible impact, adapt your decisions in order to accommodate the new information. 

Scrum is based on that same principle. The roles, events, artifacts are all prescribed to aid in the transparency, inspect, adapt process.  As you get people to appreciate the empirical methodology, it will be easier for them to start understanding the benefits of Scrum. 

... all they want to do is kanban / scrum, where they have a 2 week cadence, less meetings, less documentation, and still no product vision or guidance. 

Kanban and Scrum can co-exist very well.  Check out the scrum.org Professional Scrum with Kanban certification page and review the suggested reading, especially the guide provided there. But there is still need for product vision and guidance.  Otherwise you end up with a lot of people doing a lot of work that becomes silos of technology. If no one actually talks to the stakeholders and gives guidance how do the people building stuff know that they are building what is going to be used?

Good luck.  Come back and share from time to time. I think many people can learn from your experience. And always ask for help because that shows a respect for others abilities and skills which is a core value of Scrum and agile.  Lead by example as a good servant-leader will. 

Hey @Jon Joe 

You have tough, interesting and practical situation 😊

Specifically, higher management view is on different island. But I always believe there is still way its just we need to take right approach accordingly.

Lest see some points

1. VP wants company to be agile and he also understand implementing agile will bring great benefits.
2. VP feels why he can’t get that many projects done when there are more engineers than projects.
3. Looks engineering team is not happy implementing agile, or simple they want to work as traditional teams.

Now let’s take a step back: let’s put yourself first out of this mesh, because if we are to resolve this then you need to come out and see bigger picture.

Here we go

From your post I can see:

VP and Director is supporting you in getting the Agile implemented, but they don’t know HOW?

First: I suggest you start applying Scrum approach to solve this i.e. iterative, incremental progress with inspection and adaption.

You need to build a small flexible, collaborative team and start coaching them about Scrum framework. start implementing Scrum with that particular team.

Once one team is transformed to Scrum and demonstrate right business value delivery by coming up with Shippable product every sprint, sure other team will understand benefits scrum process framework and adapt it fast.

Secondly:  Start coaching higher management (VP, Director) about Scrum as well as Agile leader accountability and responsibility. once they understand the role of Agile leader, I am sure they will support in creating environment where Scrum team can flourish and this will help in enacting scrum across teams.

Yes, you have to play with Scope, Time and cost triangle well in this situation. you need to make them understand goal is still same but by using right approach to do right thing in right way.

Moreover, once everyone sees incremental delivery with business value in small interval, they will understand benefits of time to market and quick feedback loop for product development.

I can say one thing; I know this is tough for you but possible to implement 

Best of Luck

Sunil Gulia

Honestly, I have no idea what to do at this point other than to just try and preach the scrum guide,

How is the flow of value currently being visualized, and quality managed? To what extent does the establishment of transparency over the present situation lie under your control?

If you have a task or story board of some kind, for example, can the use of this be improved to better evidence the truth?

Last year the company paid for all the engineers to get their CSM... All of the engineers took the training, and many of them have worked in scrum prior to being here. The managers are WELL aware of agility and scrum, as is the director and VP. 

It's a situation of I want the toy but I don't want to pay for it, and I want it today I don't want to have to wait for it... It's just unrealistic.

I have created reports every two weeks where the teams themselves have an entire slide presentation to the director / vp and show them exactly what it is that's blocking them, most of which is lack of prioritization or scope definition, and process issues related to how our Operations works with Engineering. How the teams are structured, their skill sets, their work load etc etc etc.

The VP is well aware of the situation, I don't know how he couldn't be, the evidence is literally ALL around him constantly, and the Director is DEFINITELY aware as we've had multiple conversations about it.

Hands down our biggest problem is we have 0 product owners, literally NO ONE understands the Technical side and has access to the business with reasonable turn around times to be able to articulate a backlog to launch a team from. Our best current guess is hoping if we take an engineer and put them in that spot, someone with a strong personality, and try our best to get the business to respond to their requests, we can kind of limp along but it's a pretty rough impediment.

We don't even have Sprint Reviews because we have like 40 customers, which are all managed by a team that communicates like a middle man. So, we can't even get direct feed back or show them anything. Not to mention, at least half of the teams can't actually release an increment every 2 weeks because their work takes much longer to complete, we're having them basically scrumfall atm.

Basically, none of the teams have any idea of product vision, they're working off requests that come at them from left and right with no prioritization, just who yells loudest that week, and our director isn't even fully aware of all the projects these teams are working because it's just a mess.

We've been trying to get a prioritization of the 65 things, which doesn't account for roll over from last year, maintenance, etc. It's almost May and still nothing. 

I am 100% sure I'm not the problem, I've done the best I can do to make blatantly obvious almost to the point of "whining" about the real issues, it's up to management to hire and re-org at this point imo.

As a small follow up, working with JIRA, I do want to understand exactly where the Definition of Done should be placed. 

Currently, I have the teams using Epic's to define their projects. Let's say building a car. Then we use features to define, well features of that car, like the radio etc. Then we use stories to define the work needed to build that radio. Currently, I'm having them write the definition of done at the story level, but upon listening to several online videos I'm starting to question if that's not at the feature level? 

We can't really get team buy in or team commitment to a story that only 1 guy is going to work on, it just feels forced and unproductive. Should this be at the feature level?

As a way to try and help teams define their priorities I created a spread sheet that basically asks them for their features, and how valuable they believe they are to the business. Then, once the stories are made we have the dev's put their effort points in t-shirt size relative man hours, then we divide those by the business value and priorities the stories and features to be worked based on the highest return for time. This was the only way I could think of to help with establishing some sort of priority for teams. Was this a good idea?

Boy, that is one heck of a challenging environment you are in.The VP has successfully turned his problem into your problem. And that the VP is forcing you to "self organise" in the exact way that he tells you to.

The sad part is that by being cheap, the VP is losing a lot more money in productivity than the extra cost of a decent PO would be. The main advice I would give you is to try and make the costs and the impact on the teams of the current way of working transparent and put it in the VP and director's faces.

Also tell the VP that "No, under these circumstances we cannot work the way you want us to". Self organisation is key in any Agile setting, so self organise yourself out of this madness. Just do something else. If they persist in you "doing Scrum", then provide the list of impediments that need to be resolved before resuming.

Maybe sending the VP and the director to a PSM training could give them some helpful insights.

As to where to best put the DoD: print it on a large piece of paper and put it on the wall. Maybe even put it next to the coffee machine. Make it the start page of the team sites. Make it the wallpaper of the VP's PC. Just put it anywhere where people can see it.

I have created reports every two weeks where the teams themselves have an entire slide presentation to the director / vp and show them exactly what it is that's blocking them,

Jon, why are you waiting 2 weeks to inform management about what is impeding your teams?   This should be a constant notification.   You serve the team best when you are vigilant in trying to mitigate anything that is negatively affecting your team's ability to deliver.

Basically, none of the teams have any idea of product vision, they're working off requests that come at them from left and right with no prioritization, just who yells loudest that week... We can't really get team buy in or team commitment to a story that only 1 guy is going to work on, 

I'm assuming you already know that none of this is Scrum, that this is all reminiscent of old PM practices, and that you basically have a "work group" that does "stuff" - nowhere even close to a "team".   That said, I'm curious if your VP is aware of this as well, and whether he cares or not.   If I were in a similar situation, I would be constantly indicating that what we're doing is not even close to Scrum, so there shouldn't be any expectations around potential Agile/Scrum benefits.

Jon, why are you waiting 2 weeks to inform management about what is impeding your teams?   This should be a constant notification.   You serve the team best when you are vigilant in trying to mitigate anything that is negatively affecting your team's ability to deliver.

I am most certainly not waiting 2 weeks because I want to, the Director literally got tired of my daily impediments emails... Not to mention, teams literally just got tired of reporting stuff that went ignored. Our Director checked out for 2 straight weeks when she first got assigned to this division at the beginning of the year, after being heavily involved the latter months of last year. 

We've had several conversations acknowledging that we're far out in left field and not even remotely Agile. The VP is aware that it's not working well, and he's pushing the Director to help shape it up with my help. When, we have the least control to do so.

I'm not allowed to talk to the VP directly, I'm not even allowed in the manager meetings. I've been told to "stay in my lane" and only worry about scrum. So, my responsibility to the Organization basically gets thrown out the window. 

• Leading and coaching the organization in its Scrum adoption; (Not allowed to do this, I get told to let the Director and Managers do this.)
• Planning Scrum implementations within the organization; (Not allowed to do this either.)
• Helping employees and stakeholders understand and enact Scrum and empirical product development; (I am only allowed to handle the first part, most of our engineers can't even identify our stakeholders...)
• Causing change that increases the productivity of the Scrum Team; and, (This I have done effectively imo.)
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization. (We only have one scrum master, me, for 8 teams.)

As you can see, it's not scrum. Send help. LOL

The VP is aware that it's not working well, and he's pushing the Director to help shape it up with my help.

Then you seem to have identified the VP as a potential sponsor.

When, we have the least control to do so.

Attempts to delegate responsibility for change downward are very common, but rarely successful.

I'm not allowed to talk to the VP directly

Suppose you did so anyway, or at least announced your intention to do so, with the objective of helping the VP to communicate a sense of urgency for organizational change (as per the Kotter 8 step change model). Suppose you also started doing the various things in the Scrum Guide you are apparently "not allowed" to do. What would the consequences be?

 Suppose you also started doing the various things in the Scrum Guide you are apparently "not allowed" to do. What would the consequences be?

I would basically be completely shut out of my Director's office and I might even get replaced. I've already been told if she finds out any of the information I am privy to gets leaked to the engineers that I will not be told anything going forward. 

The VP considers me to be like an Engineer and expects me to work through my Director, I set up a 1 on 1 with him already and explained what we needed was Product Ownership, and the Director over road me and said that I wasn't privy to the real issues and that she would work with me to help me understand. Which is when she informed me of just how broken everything is, and how unreasonable the VP is...

I met with him again and explained again some of the major barriers, and he sent me back to the Director. So, it's literally just a re-delegation. I'm honestly scared at this point, I actually do need this job until July so I can get my official 1 year mark and then I have more options for moving if I absolutely have to.

I do actually like the people I work with, the job is great, I love the challenge, but I am tired of feeling useless and incapable of actually producing the change the VP says he wants. Apparently, upon talking with others who have been here for 10 + years, this is far from news, it's been this way since the VP got here.