Scrum Method

[CaptainCrunch]

As I've talked about I'm taking the PMP certification course, the first part of the course focuses on the Scrum methodology.


I wanted to see if any of you were using of this method or masters of it, and how its worked for you. I wanted to see if I could gather some real world benefits from the brain trust here.

[photon]

I've never been on a team where we adhered strictly to any specific methodology.

Process for the sake of process is doomed to fail IMO.

Every team I've been on has tried to pick aspects of Scrum (or agile or whatever) that served the needs of the team and ignored the rest.

I think part of that comes from the rest of the organization lacking a commitment to being agile. I.e. management just wanting to hear that feature X will be delivered by date Y despite not having the information available to actually know that, which results in a pesudo-waterfall-from-experience guess about if something is doable by date X.

But I've been on teams where a sprint just didn't make much sense, and we just worked from a Kanban instead. Standups seemed to be pretty common regardless. I think too many teams ignore retrospectives so don't improve over time and get stuck.

One team that was probably the most adhering to it I was on it seemed more time was spent on the methodology than was spent on actual work; it felt like I had maybe 2 or 3 days in a 2 week sprint to actually do any work.

I get that structure is needed, but process should serve me, not the other way around. Find what helps.

Except retrospectives, always do those

[bluejays]

From a few people I know who are Scrum trainers and such, who've actually had input on the PMBOK, say the classic waterfall is dead for software for the most part. They also weren't a fan of PMBOKs reference of agile and scrum for what it's worth. I guess it's an academic thing to disagree with things but these guys think the PMP methodology is now a cash grab because very few industries adhere to such rigidity. I remember studying for PMP 8 years ago, and while it was enlightening at the time, I ultimately found Scrum to be a better framework for the modern work environment, so I didn't end up taking the PMP exam (right or wrong). Scrum is a little more idealistic though, in that it doesn't prescribe word for word what should be done, which leaves room for organizational paradoxes that you really have to think what the best way to do things given your organizations constraints on sharing resources at the right time. I don't work in a scrum environment day to day, though I was certified about 2 years ago and think it's worthwhile from a knowledge perspective to have a formal way of guiding yourself (like any methodology).

[CaptainCrunch]

Thanks for your feedback. I'm trying to figure out how this works, and I'm probably jumping ahead.



From my understanding this is about breaking projects down into bite sized pieces where you breakdown a project. Create a project backlog about features, from there you create a sprint backlog of tasks, and then hold daily meetings to discuss what was done yesterday and what is being done today and impediments.



From my understanding the Scrum master is there to coordinate between the Product owner (Who coordinates with the company or client on the backlog), and the development team or project team and keep the project on task for the spring right.


It all seems efficient, I guess what I'm missing and it might come later is


Who does the breakdown of the phases or sprints?
Who coordinates the changes in backlog, is it the product manager or the scrum master

[CaptainCrunch]

Also if any of you have any recommendation on management software that utilizes Scrum/agile that's open source so I can play around with some projects, that'd be in a word amazing.

[nfotiu]

We use Jira for KANBAN and Sprint boards at the large org I work. It looks like there are free versions available and demos on their site.

[dobbles]

When I was working in software marketing, we implemented agile scrums similar to the software teams. The mandate was from pretty high up so it was adhered to pretty well. There was tons of administrative overhead and meetings, but that was kind of the status quo regardless so it just felt like normal.

I felt like it was successful in that the different business units knew there were limited resources and turn around time was much higher than it was before the change. So they did actually plan better and have a better idea of what they were asking for and what the implications of the ask were. The business units and the scrum masters worked to prioritize needs and then the scrum masters would work with individual contributors to know what was feasible.

We used Hubspot to train our team and help us come up with our parameters but did not use their software as we had in house tools that could track for us.

[photon]

Yeah every company I've worked with for a while now has used Atlassian stuff.

I've wanted to give YouTrack a try, and they just added a free tier. I like JetBrains' software development tools but I can't speak specifically to YouTrack.

[bluejays]

Originally Posted by CaptainCrunch

Thanks for your feedback. I'm trying to figure out how this works, and I'm probably jumping ahead.



From my understanding this is about breaking projects down into bite sized pieces where you breakdown a project. Create a project backlog about features, from there you create a sprint backlog of tasks, and then hold daily meetings to discuss what was done yesterday and what is being done today and impediments.



From my understanding the Scrum master is there to coordinate between the Product owner (Who coordinates with the company or client on the backlog), and the development team or project team and keep the project on task for the spring right.


It all seems efficient, I guess what I'm missing and it might come later is


Who does the breakdown of the phases or sprints?
Who coordinates the changes in backlog, is it the product manager or the scrum master

It's been a couple years since I've taken it, so forgive me on this. The job of the scrum master is to ensure that the development team is off and running with the Product Owner not coming in and making changes. So at the start of the sprint, the full team with the prod owner takes a look at the backlog. The prod owner owns that but it's visible to everyone. The PO says we need x, y, z to be done at some point (the backlog). The development team selects what they think they can get done within the sprint. They also ask endless questions about what features are included for clarification purposes and where needed the PO breaks down features further into smaller bits on the backlog if it wasn't properly broken down. It's the PO's job to clarify and break down the backlog further. The PO is not telling the developers how to do their job, that's what a self sufficient team should be doing themselves. The PO is filling in gaps on what features he needs and the dev team develops it but before that asks all the questions they have up front about those features. The SM simply facilitates the conversation to be productive at these sessions, and during development does some running around to prevent roadblocks.

[McG]

One thing not mentioned is the funding model. I find that Operating projects are much more scrum friendly than capital projects. Capex projects tend to have funding or capitalization deliverables and therefore tend to have specific Delivery dates. Also, I think that finance people like the predictable waterfall approach.

Having said that, with awareness and care either scrum or waterfall can be used for either funding model.

Just another thing to add to your knowledge bank!

[CaptainCrunch]

Ok, now I get where new complex projects are handled or multi-projects are handled through Scrum of Scrums.


So would I be thinking that in terms of development where you have lets say project A working on the development of lets say a application, and Project B which needs aspects of project A in order to be able to create an over arching application that you would have to have daily scrum meetings for A and B, but have a scrum of scrum meetings lets say bi-weekly to be able to coordinate the information flow and create and overall product backlog?

[r00t]

I used to do agile transformation via a consulting firm and now run the agile delivery org (20+ SMs) at a company in the city.

Scrum itself is relatively straightforward. It's only about 19 pages and basically speaks to the key attributes of scrum: ceremonies, roles, and artifacts.

3 roles: Scrum Master, Product Owner, Team Member
Ceremonies: Daily Stand-up, Sprint Review, Sprint Retrospective, Product Backlog Refinement, Sprint
Artifacts: Product Increment, Product Backlog, Sprint Backlog (I'd add a risk or impediments log here too)

Typically, work is broken down into 2-4 week increments called sprints and a small (5-9 people) cross functional team delivers within that time box.

Soapbox moment: If an organization is talking about digital transformation and agile, they likely don't realize the scope of change they're talking about and believe that adopting scrum as a "project management" methodology will deliver better outcomes. 19 pages of framework which basically assumes high performing, "t-skilled" team members with intentional proximity to the actual problems flies in the face of a century of Taylorism and specialization.

To your larger question about scale, scrum does tend to require deliberate co-ordination when there is work that can't be completed entirely within the cross functional team (think specialized skills like ERP, mainframes, etc.) or if it is a larger program and the scrum teams likely start to reflect different features (feature teams) within the larger program.

PMI acquired Disciplined Agile last year so they are likely growing their certifications beyond the PMI-ACP into the DAD space.

From a tooling perspective, JIRA is definitely out in the wild with likely the largest market share but there are tons of tools out there like VersionOne, Rally, LeanKit, Kanbanize.

Happy to share more if there's any more detail you want to get into. I've run a couple of large scale agile programs so I'm full of war wounds on successes and failures.

[Kerplunk]

Like said above, scrum is pretty straight forward. You write your requirements out, figure out the work required for each, break them into sprints of set time frames, and work to get all that you planned done. At the end is a product that should, in theory, have all of that work done which can be showed to the product owner/customer

Where I work we have....mixed adherence to various scrum principles. While we tried to get all the teams to do the exact same process, things started to fall apart depending on the project that it was being applied to. Our projects department, which builds off the shelf (ish) software, tends to get bogged down in contracts that require huge re-writes and almost no staffing. These teams have cut out a lot of the process (sprint retrospectives, reviews, and a few other things) to streamline our work to get things done so we can get paid.

The teams that work on a contract basis tend to follow most of the methodology and it works well for them. The key there is that the product has well defined requirements, a generous timeline, cost plus billing, and customers that also adhere to most of the same processes. Although I would run if someone ever comes to you and asks about using SAFe.

We use TFS and Visual Studio for pretty much everything, although Trello is used for some boards if the people are ambitious enough to duplicate the work.

I like some parts of scrum, detest others. Constant updates with team members keeps us aware of what is happening, and having a well written backlog of items to work on keeps the focus of the product and serves as documentation about what the thing should do. Almost every review and retrospective I have been in has been a waste of my life, but that could be due to a number of factors, including my hatred for meetings of any sort.

Feel free to message me if you want to talk about anything.

[CaptainCrunch]

I can't tell you guys how grateful I am about your feedback and participating in the discussion, it means a lot to me.


I finished the first segment of the course today. which covered the basics of scrum, the breakdown of responsibilities, the steps in the Scrum method, and the 72 reasons why its a good thing.


I do like a lot of aspects from it. I've been involved in too many projects from the outside looking in that have become convuluted messes, with too many people fighting for ownership of too many tasks, and the chaotic meetings that follow.


I've kind of figured out the roles, and that all of the sprints don't really have to start at the same time, for example that one backlog for example needs another product to be finished first. So it makes sense. I also really like the idea of the Product Owner taking ownership of spec, and breaking it down in the backlog, and the Scrum Master acting as almost like a facilitator.


I really like the concept of the Scrum Meeting format of no more then 15 or so minutes and it only addressing four key queries.


What did you do since the last meeting
What are you doing between now and the next meeting
What are your impediments.
And in theory, what impediments are you going to cause.


The last segment of the first course that I completed dealt with Scrum of Scrums if your involved in multiple interlinked projects so to speak.


There's really a lot of self management in this method. The developers are responsible for managing their assigned part of the backlog. The Product Owner almost acts like a translator between the customer/client and the development team in terms of backlog and change orders.


I also like that the spring emphasizes actual tested deliverables at the end.


I can see the benefits, and I'm hoping that I got this all right.


But hearing your real world experiences is really helpful.


The next segment that I start on Monday is around Jira Agile use so that should be interesting for a dummy like me.

[FlameOn]

Originally Posted by CaptainCrunch

As I've talked about I'm taking the PMP certification course, the first part of the course focuses on the Scrum methodology.


I wanted to see if any of you were using of this method or masters of it, and how its worked for you. I wanted to see if I could gather some real world benefits from the brain trust here.

Hey Cap! Getting your scrum master training and your agile training will help you a lot in the development world. It helps a lot with the organization, setting of expectations, time line planning, and prioritization at my company. About a decade+ ago my company at the time was a waterfall, upfront design and documentation shop that experienced a lot of development delays because of process issues, and us transitioning to Agile really helped focus our priorities and continuously deliver consistent releases.

I got my Agile black belt and Scrum Master certification earlier in my career, took the certification course from Quadrus at the time, and it helped me when I started taking a more senior role within my team. They had a really helpful instructor back then. Thinking about getting my PMP as well, just need to sit down and focus on it.

Like other mentioned most of our stuff has migrated completely over the the Atlassian set of tools with Confluence, Crucible, Jira, Jira Agile, and Zephyr. This seems to be the standard these days with our company and almost all of our overseas and American vendors. Tools to look into if you aren't already familiar with them.

[Bill Bumface]

IMO, Scrum by the book is mini-waterfall. You have up front planning instead of just in time decision making. You have a push model of working where scope and schedule are fixed every 2 weeks. You have a choppy workflow that inherently leads to natural behaviours of throwing things over the fence from Product to Engineers to QA.

I do think Scrum is a great transitionary step, but as others have said, regularly examine what aspects are providing value to your team in their context within your business.

I personally like optimizing teams around cycle time and a pull model of working. This naturally leads to a few behaviours that are beneficial. Humans are ####ty multitaskers. Limiting work in progress lets everyone be more focused and produce better work more efficiently. It also leads to flow. You don't want work waiting for someone ever. The shorter the time from a design decision to QA sign off means less to keep in people's brains and a higher chance of a team delivering a feature with shared context and ultimately delivering the intended business value.

Nothing is perfect. Every team has different needs at different times. An effective introspective framework is critical.

The biggest challenge is almost always the broader organization and their approach to budgeting. Investments should be made in delivering value to customers vs. sanctioning projects with defined endpoints. Decisions should be made as late as possible with as much recent information about your customer as you can get your hands on.

[CaptainCrunch]

So I started on the Jira Agile Course today. Signed up for the free cloud version of it.



It was funny, because I'm going through the course, setting up my project as per the course and half the stuff that they were talking about wasn't there, so Cap blew his ever loving gasket.


In the new version, there are two different project selectors, either classic or next gen. Well nowhere in the course does it talk about these two templates. So of course I went with next gen, and for example components are missing.


So then, I had to go back and start over in classic.


I guess lesson learned as I try to get more poor sample wordpress development agency program off the ground.

[r00t]

Fun fact: next Gen makes JIRA slightly less hellish in terms of providing teams with autonomy to manage their work according to their needs instead of the centralized JIRA admin. It also is slightly better at Kanban (but not much is worse than JIRA classic so the bar is very low)

Additional fun fact: Next Gen projects have worse reporting than the already terrible JIRA reporting capabilities.

Long story short, JIRA knowledge is important because the market dominance of the tool but there are many limitations within the tool that will force behaviours that maybe don't quite jive with the original manifesto.

Sorry for the rant, I had a bit of a frustrating day trying to visualize my team's work in progress...

[CliffFletcher]

Standups according to scrum model: 5 minute meeting where team members bring up any roadblocks or issues they need to share.

Standups as practiced by every team I've been on: 15-20 minute meeting where team members recount everything they've done in the last 24 hours to justify why they're being paid.

[CaptainCrunch]

Originally Posted by CliffFletcher

Standups according to scrum model: 5 minute meeting where team members bring up any roadblocks or issues they need to share.

Standups as practiced by every team I've been on: 15-20 minute meeting where team members recount everything they've done in the last 24 hours to justify why they're being paid.

Yeah, I was thinking that I could see where Standups could get out of control if you don't have a strong master running them.


I mean the questions.


What have you done since our last one


Could slide out of control


What are you going to achieve before the next meeting


Could lead to finger pointing


What are your current impediments



Could be a blame game


What impediments are you going to cause


Hurt feelings.