Madness Project Nexus Trainer
Gene Cryder
So, I've been hosting lunch and learn sessions where I'm trying to coach the org on scrum values. It's been very humbling for me, because as this is not even my first full year being a scrum master, I've been stumped a few times and had to admit I'll need to do some research on that. Such as this scenario, thus the post.
So, currently I have a scrum team that uses JIRA, they have an epic, they've created features which represent the work needed to complete that epic, and each spring create stories to represent the work needed to do a feature, or a couple of sprints worth of stories.
When it comes to definition of done... It's suppose to be a team wide agreement. However, each story is assigned to an individual and the work to complete a feature is getting individualized definitions that are then "agreed" upon by the team. However, none of the team members really understand that work as they all have different skill sets and it's basically just the guy telling everyone what he plans to do.
I was explaining that stories should be written by the team together and not handed out individually, and I was asked why that's valuable, when what they're currently doing is working. I was stumped. I had to back peddle and say something like, well if your team has agreed to do it that way and it works, then that's fine. But, it's a great question... If the stories are assigned to individuals, how can the DOD's be team agreements? Also, if we're asking the team to write stories together including all their contributions, aren't we just having them define features and story point them?
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.
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.
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.
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.
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.
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?
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.
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.
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?
e59dfda104