4

I've got of an involved question, here. (Apologies if I provided too much unnecessary explanation; if so just skip to 'The Problem') First, let me explain...

The Situation:

We're a middling-size company with a relatively small development department - 7 people. Until recently, pretty much all the work that came in was fairly small stuff, assigned to a single person, with the only project management being a simple ticket system (which no one even really used that often, anyway). Now, however, we've got a significantly-sized project - estimated at 18 months. For the sake of this project, we've started using actual project management techniques - in this case, Scrum.

The Team:

We started the project with a team of one full-time employee developer, two contract-employee developers, a Product Owner (her theoretical job title is 'project manager', though because we're so understaffed she ended up also being Product Owner, BA, and QA), and the project owner, who is the CIO. We recently (a few months back) also folded a senior developer, who works with completely technologies and has some trouble communicating effectively, into our team to work on certain tasks only she can accomplish - or even fully understand. The developers all work together, in a single cubicle, while the PO and CIO work in a separate building, about a two-minute walk away. The PO is great, having recently completed a Project-Management-Scrum course before being hired, and the developers were anxious to finally get some sort of project structure, so we've generally got good buy-in from them. As for the CIO, his opinion was along the lines of 'I don't care how you organize yourselves, just get it done.' This later morphed into slight push-back when he realized how different Agile was from the Waterfall he's used to, but since everyone else in the department strongly dislikes Waterfall, he's mostly backed off - but also remains mostly uninvolved.

Myself:

I am one of the aforementioned contract-employees. I'm also a junior developer... and also the Scrummaster. A strange choice, I realize, but since I'm the only one who's had any actual experience with Scrum, I was pretty much nominated. I'm not a certified Scrummaster by any means, but seeing as we're a year into the project and nothing's on fire yet, I figure things aren't going too badly.

The Problem:

We started out doing Scrum mostly 'by the book' (Scrum from the Trenches, specifically) - daily standup (which consisted of developers), pre-planning meeting (where just the developers hash out the technical details of stories), planning meeting (where the devs estimate the stories with the PO's assistance), demo, retrospective.
However, for the daily standup, demo, and retrospective, interest quickly waned.
There were several mild complaints about the daily standup - "Why bother, when we all sit two metres from each other all the time?" Of note is the fact that neither the PO nor the CIO were present at the daily standups (should they have been?). So over time, as people were late or busy and I'd forget to conduct the meetings, they just sort of got phased out, and we don't do them anymore.
As for the demo, we originally had the CIO involved, but he was worried he'd stifle the project after there were repeated occasions of him mentioning a change and that change not being implemented immediately - leading to him mistakenly believing that we wanted him to stop providing feedback, so he stopped attending fairly early. Several months after that, it was decided that we needed to start having Quality Assurance... despite not having a QA. So the PO got roped into becoming the QA. And so, since she had already gone over every single story during the QA process, she considered attending the demo to be redundant. After that, the demo pretty quickly got dropped, as focus shifted to completing features over 'wasting' time preparing and implementing a demo that only the developers would see. I've brought up the remaining benefits of the demo (that it's a good form of retrospection, and that it's a useful additional bug-check), and while the other developers agree with me, none of them seem to have any interest in actually putting forth the 5-minutes-of-work-per-story to actually accomplish a demo.
And now, as we near the first milestone, pressure mounts, and stories become increasingly less-well defined (did I mention that our PO is also a BA AND a QA?), the retrospective and pre-planning meetings have started falling off as well. I've received much positive feedback about the pre-planning, so I'm sure that will pick back up again once the milestone passes, but I worry the retrospective may end up dead in the water as well. I haven't even bothered attempting to fold the senior developer into the retrospective, since she's well behind schedule and working on a bunch of different projects at once. Should I attempt, regardless? What about the CIO?

While I realize that part of Agile is the ability to modify processes to fit the environment, I worry that these meetings have been erroneously, or at least prematurely, pruned. It's possible that my own lack of understanding of, or inability to convey, the purposes of these meetings has contributed to this.
Should I just accept that these meetings don't fit well into this organization and allow them to disappear? If not, what can I do to improve buy-in for them? Should I request that the PO attend the stand-ups? Can/should I just exercise my 'authority' as Scrummaster to force people to attend these meetings (keeping in mind that I have little formal authority, since my official position is junior developer, not Scrummaster)?
What do I do?

  • No time for an answer, but some I'd say the demo & standup becoming redundant is good. Your team is working so closely together they don't need them. However, whatever you do, don't let the planning meeting and retrospective go the way of the dodo. They're far too critical. "With retrospectives and enough time, we could reinvent all of the agile practices.". Your team may be primed for a transition to Kanban, or you may be slipping into a flat spin. It's hard to say, but you need to be vigilant right now. It's a turning point for the team, better or worse. – RubberDuck Aug 20 '16 at 0:27
  • 1
  • 1
    @CodeGnome - Yeah; the sad part is that even with that, the sockball we're currently playing is overall probably still better than what we had before. I'm trying to bring in more Scrummy bits as I can, but as expected it's slow-going. – Sarov Aug 22 '16 at 22:59
  • If you are seeing some positive traction, CONGRATULATIONS and keep it up! – Alan Larimer Aug 23 '16 at 12:42
5

There are two parts to the Scrum Master role:

  • Helping the team to resolve impediments
  • Ensuring that Scrum is being followed

The second part often gets neglected, but it is very important.

If the team does not see value from the Scrum approach they will quickly stop following it. The Scrum Master should coach the team to ensure they understand why it has ceremonies like the stand-up and retrospective.

If you just tell the team to do the ceremonies then sooner or later they will stop doing them. They have to understand why the ceremonies are valuable.

Daily Scrum

The daily Scrum is a classic example. Many teams treat the daily Scrum like a progress meeting. Development teams rarely see value in progress meetings and so they often fall by the wayside.

If you hear things like this at your daily Scrum then you have a problem:

"It's almost the end of the sprint and we have loads still to do."

"Is that story fixed yet? We are getting behind."

"Is that all you managed to do yesterday?"

In fact the daily Scrum has nothing to do with measuring progress. It is all about synchronisation. That is why the conversations at the daily Scrum should be related to synchronisation matters.

You should hear things like this at your daily Scrum:

"I'm going to rebuild the QA server today, so won't be able to do any testing"

"That bug we found yesterday is a real problem. Can anyone help me with it?"

"Yesterday I got most of the first page done, would anyone like to see a demo?"

It is worth noting that most Scrum teams have the Product Owner present at the daily Scrum. This helps to reinforce that this is a Scrum Team meeting rather than a development team meeting.

I wouldn't invite your CIO as they don't have a Scrum role and are not part of the Scrum Team.

Retrospective

For restrospectives it is important to realise they are about improvement. The idea in Scrum is to work smarter rather than to work harder.

Make sure you focus on demonstrating value in the retrospectives. For example, teams typically take one or two items from each retro and say they will fix them in the next sprint. Then, at the next retro they check to ensure they did manage to make those changes. If retrospectives just focus on problems and not solutions then they quickly lose value.

Sprint Review

Finally, the sprint review. This is a key aspect of Scrum because it:

  • Substitutes for reporting
  • It is the time when the team corrects its course (ensures it is doing what the stakeholders want)
  • It is the time when a lot of change gets injected into the backlog

The idea of Scrum is that the team focuses on delivering customer value. If you are not engaging with your customers then you have no idea if what you are doing is what they really want.

You may be working hard, but there is little point in working hard on the wrong features or features that are not a true priority to the stakeholders.

3

Scrum has exactly one authoritative 'book': The Scrum Guide. I haven't had the opportunity to read Scrum from the Trenches yet (it's on my list) and I am sure that it has valuable information in it.

The purpose of the Daily Scrum is for the Development Team to inspect Sprint progress, synchronize, and plan. If it is conducted as a status report or the purpose isn't met it can become stale. Just because the developers are collocated, doesn't necessarily mean that they are working together.

The lack of definition in the stories is an issue. They goal is to deliver value to the customer early and often; if you don't know what they want, that is an impossible goal to achieve. This needs to be discussed with the Product Owner. The issue certainly comes to light in the Sprint Planning event. It would be more visible if Product Backlog refinement was occurring within the iteration. If nothing else, this could be discussed at the Sprint Retrospectives.

Were customers invited and participating in the Sprint Reviews? Calling it a demo negates its purpose and diminishes its value. There is extensive purpose for the event, missing those does create a senseless to it. Also it is an important opportunity to receive feedback and input from the customer.

If the Scrum Team or Development Team is not working collaboratively, that is a root issue which needs to be addressed. It was possibly good that the CIO has some training, if it were quality; there is a lot of "Agile" training out there that furthers ignorance to the Manifesto and specifics such as Scrum, DSDM, and XP.

RubberDuck's comments are worth considering when the agile software development team and organization are mature in living up to the the agile values and principles.

Hopefully this is helpful and not too disjointed in my sleepy state. Please ask for clarifications if desired.

  • "Were customers invited and participating in the Sprint Reviews?" No, it's pretty much been mandated by the CIO that the customers aren't supposed to see the product until it's almost ready to be given to them (and, being a rather large product, this is only recently the case - a problem with Scrum's mandate to have a releasable product every sprint, but that's a separate issue). It's hardly ideal, but there's nothing I can do about it. – Sarov Aug 20 '16 at 4:19
  • It sounds as if you are in a Scrum in name only situation. I empathize with your frustration. – Alan Larimer Aug 20 '16 at 17:02
  • 1
    @Marut: Scrum mandates that you produce a "potentially shippable product increment", which means that your product should have the right quality to be able to ship it, but it might not have enough functionality to make actually shipping it a viable business decision. At a sprint review/demo is should be possible for the stakeholders to say "we want to ship this right now", without the developers interjecting "but we still have to do X, Y and Z before we can ship". – Bart van Ingen Schenau Sep 1 '16 at 11:29
0

You story sounds very familar to me. You should drop scrum and do 'no-process'

Standups and Demos are not for the benefit of developers. If your PO and CIO dont understand or care about them then you are not in a position to make them work.

Here are some hard truths about scrum.

The daily scrum : The purpose of this meeting is to report progress to the PO and ensure developers dont get pulled off onto other projects/low priority features or facebook.

If the PO dosnt at least check the board to make sure stories are being done. Dont bother with it.

The Sprint Demo : This is QA the PO and stake holders can see whats been done. Bugs are immediately apparent. If stuff looks crap they can make a fuss.

If stakeholders dont turn up to the demo. Dont do it.

All the scrum meetings have good purposes behind them, they try to make managing a project easier, predict whether you are going to hit your deadlines etc. But its really for a PM to care about these things. If they dont you should concentrate your efforts achieving what the business DOES care about. Presumably adding features as fast as possible, which, assuming the specs are understandable, you can bash put without any meetings.

  • 1
    The stated "hard truths" exemplify misunderstanding and/or poor execution of the Scrum framework. You are correct that you cannot change the culture. Those who believe that the Daily Scrum is a status reporting meeting, the Product Owner manages the Development Team, the Sprint Review is a demonstration, etc. do not understand the framework and probably do not want to follow the agile software development values and principles. – Alan Larimer Aug 23 '16 at 12:41
  • its all very well potificating about the true understanding of the framework, but you forget that your real job is making you boss happy – Ewan Sep 5 '16 at 13:17
  • 1
  • jim ignored his boss and did some crazy shit 'for the project!', what happened next will amaze you! – Ewan Sep 13 '16 at 22:41
  • @Sarov Interesting read. The roots of the Manifesto for Agile Software Development were to better serve the customer. Sadly, many still focus on pleasing the boss while the boss continues to lack focus on delivering valuable, working product to the customer. Too many organizations continue to work in a top down, command and control, the boss knows best, "yes man" promoting way. Perhaps someday these people will learn to let go and truly collaborate. – Alan Larimer Oct 6 '16 at 13:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.