(Part 2) Top products from r/agile

Since you're aiming for one hour planning, I can conclude that your sprints are one week long? Good, the shorter the better, but if they're not you need longer planning sessions... The planning in Scrum is relative to the sprint length, and would be about 1 hour for a one week sprint, twice that for a 2 week sprint, etc.

And yes, it is usually longer for a team that is new to this. Three planning sessions is not a lot of experience.

Now for some generic advice. Just the things I usually do with a new team, if they'll let me.

The goal of the planning session is not to get an accurate forecast of exactly how much work can be done in the sprint. Sounds weird, I know, but there you are. It is means to avoid taking in too much, or so much that it'll cause undue stress to the team. A development team can't do their work well (as in: keep quality high) if there's too much pressure one. The concept of tracking velocity is purely meant as a protection of the team, and by extension the quality of the work.

The goal of the planning session is to ensure that everyone in the team knows exactly what a story entails, and what you'll have to do to get there. That includes the PO (otherwise she'll be surprised at delivery...), your analysts (idem), QA (it helps if you know what you're testing) and developers. The discussion you're having is the sole reason for this session, the estimate is an excuse to have that discussion.

That said, normally, the team has discussed these stories before. If you follow scrum, you should be having refinement sessions (5-10% of team time is supposed to be spent on refinement) that are means to discuss the goal of the story (why do you want it?), and what is, functionally, expected at the end. I recommend looking up the idea of CCC (Card, Conversation, Confirmation), and reading up on BDD (Behavioural Driven Development) or ATDD (Acceptance Test Driven Development) to help you get better at the Confirmation part. Have these sessions with the entire team, certainly at the start.

Having that kind of clarity before the sprint (and its planning) starts will help a lot in keeping the planning session focused. Usually, estimation is also part of the refinement, if you do estimation. Doing estimation of stories for the first time in the planning session is Not A Good Idea.

I recommend not spending too much time on estimation, but simply force short stories, like /u/hello_timebomb was saying elsewhere in this thread. If a story is small enough to do in roughly two days (by a pair of developers, plus testers), then it's small enough. Making 'm small like that is an art, but you'll get the hang of it, especially if you do the ATDD/BDD things mentioned above. It will also make it much easier to combine the knowledge of analysts, testers and developers: can we do this in 2 days? If one of the roles things that's tight, the whole won't fit. (But use those opportunities to find out how they can work together more intensively: hand-offs are a problem.)

Then, having the PO introduce the stories can be a lot quicker, so the first part of the planning session (what do we want to build? Roughly how many of the top stories can we pick up?) is fast. Sometimes, the PO leaves after that, but I usually keep 'm around in case any additional questions come up.

Then, the team needs to discuss in more detail how they're going to implement the story. Do the same thing for tasks as for stories: a task longer than half a day (or two hours!) is too big. Make more tasks, make 'm more specific. Ensure that all tasks, for everyone in the team, are written up. Ensure that once all tasks are Done, the story is done and can move to production (even if there are other processes outside the team preventing that!). There's often design discussions, discussion of edge-cases (bring in the PO if needed!), etc. Good. That discussion is what the planning is for.

Still, while you're learning this, it will take time, but you should see this getting better on average over the first 3-6 sprints. If not, see where you can make pieces of work smaller, and get people involved earlier, and you'll be going in the right direction.

I'm a big fan of The Great ScrumMaster by Zuzi Sochova. Zuzi is a good friend of mine and has traveled the world professing Scrum - she is a board member of Scrum Alliance.

The Great ScrumMaster: #ScrumMasterWay (Addison-Wesley Signature Series (Cohn))
by Amazon.com
Learn more: https://www.amazon.com/dp/013465711X/ref=cm_sw_em_r_mt_dp_U_qr1lDbQZ74K1E

Here you can find some recommendations: https://agilestash.com/books.html

Apart from the ones in the website above, I'd like to recommend to you as well:

• Implementing Lean Software Development, by Mary and Tom Poppendiek (A fanstastic book)
  
  https://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381/ref=sr_1_2?ie=UTF8&qid=1527189551&sr=8-2&keywords=lean+software+development
  
  
• Lean for Dummies (Don't be fooled by the title, this is an excellent book)
  
  https://www.amazon.com/Lean-Dummies-Natalie-J-Sayer/dp/1118117565/ref=sr_1_1?ie=UTF8&qid=1527189536&sr=8-1&keywords=lean+for+dummies
  
  Happy reading!

> We have a primary PO, 2 SM, and separate pools of ~15 BAs, ~30 devs, ~15 testers; all grouped into 5 smaller 'agile' teams.

So there are around 12 members per team? That sounds quite large. Succeeding with Agile recommends teams of 5-7 people. I personally like having 1 tester, 1 BA, and then the rest of the team being software engineers provided that the team is responsible for delivering end to end features.

> Our 2 week sprints total 1 month in dev, then 1 month in test (PTA/UAT), then moves to production.

This sounds more like a 2 month sprint. You should be capable of taking user stories and finishing them in their entirety in a single sprint. This includes requirements, design, coding, and testing. Having a 2 week sprint duration is the most common sprint duration and works pretty well for most teams. So if your team can get your process fixed up, you can stick with 2 week sprints.

>However, a team member proposed that for requirements issues or UAT change requests, that we should always defer these for a later release; if it isn't in the acceptance criteria, it gets deferred.

Why should these be deferred to a later release? Are requirements not allowed to change? Remember the Agile Manifesto welcomes changes in requirements. It is not possible to get all of the requirements "right" the first time. Some of the requirements will emerge from what you learn from feedback as you work on the software.

>My hesitation with this is that our next 1-2 releases are planned out, so it may take 1-2+ releases to come back around and fix a small issue that was deferred.

Are you not allowed to change what you are releasing? What if the market changes? What if you demo to the client and they don't like the direction the feature is going in? Essential Scrum argues against a fixed-scope release for this reason. When planning a release, we should be able to make adjustments to our release plan to account for these things. Here is a good excerpt from Planning Extreme Programming that talks about this:

"How stable is the release plan? Not at all. The only thing we know for certain about a plan is that development won't go according to it. So release planning happens all the time. Every time the customer changes his mind about the requirements and his priority, this changes the plan. Every time the developers learn something new about hte speed of doing things, this changes the plan."

I don't think I'd start with a certification class. I'd start with two books:

• Agile Project Development with Scrum
  
• Kanban
  
  I'd also look at some other online resources (like this agile roadmap to get a sense of what you actually want to implement and change.
  
  From there, that will guide you to what classes, or as /u/mlucero14 pointed out, if you'd prefer to bring in a coach or trainer.
  
  Given that it looks like you all are in Costa Rica, you might want to talk to the team from Pernix Solutions. I've worked with them before, and they understand the agile and craftsmanship side of things.
  
  Hope that helps!

I would suggest this book. It's what we give people who take our product owner classes and is written by one of the people who helped write the scrum.org PSPO class (if I remember correctly). I took the class and the book is actually really great, lots of good strategic and tactical information you can use.

If you have any specific questions I'm also open to chat!

If you're looking to instigate significant change in an organisation then this is a good book https://www.amazon.co.uk/Agile-Organization-Design-Transformation-Continuous/dp/0133903354

If you simply want to improve engineering practices and reduce cumbersome specs I'd look to combine INVEST user stories with a good test automation pyramid that includes BDD specs co-authored by requirements owners and testers.

Apart from David J. Anderson's Kanban which was mentioned already (he is one of the lead figures that popularised Kanban in software development), I learned a lot from Henrik Kniberg's "Kanban vs Scrum"

https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf

and also a lot from Eric Brechner, who works at Microsoft and has spoken a lot about his success with Kanban. Here is his book:

https://www.amazon.com/Project-Management-Kanban-Developer-Practices/dp/0735698953

and two talks of him, if you want to watch on youtube

https://www.youtube.com/watch?v=CKWvmiY7f_g
https://www.youtube.com/watch?v=CD0y-aU1sXo

Meta-analysis of over thirty studies found no consistent effect from TDD. One clear finding was that the better the study, the weaker the signal.

Greg Wilson's lecture: http://vimeo.com/9270320
and book http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321

Wilson's post about the subject: http://www.neverworkintheory.org/?p=139

>I’m still not sure what to think about test-driven development. On the one hand, I feel that it helps me program better—and feel that strongly enough that I teach TDD in courses. On the other hand, studies like this one, and the other summarized in Erdogmus et al’s chapter in Making Software, seem to show that the benefits are illusory. That might mean that we’re measuring the wrong thing, but I’m still waiting for one of TDD’s advocates to say how we’d measure the right thing.

Behind Closed Doors: Secrets of Great Management (Pragmatic Prog... https://www.amazon.com/dp/0976694026/ref=cm_sw_r_sms_awdo_t1_AJq.AbZ0VT2WA

https://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445 could be a good start.

and Uncle Bob's blog has a lot of insightful thoughts as well https://blog.cleancoder.com/

There's plenty of literature that promotes the same things:

Drive by Daniel H. Pink

[Antifragile by Nassim Nicholas Taleb]
(http://www.amazon.com/Antifragile-Things-That-Disorder-Incerto/dp/0812979680/ref=sr_1_1?ie=UTF8&qid=1465069079&sr=8-1&keywords=antifragile)

Organize for complexity by Niels Pflaeging

Reinventing organizations by Frederic Laloux

Management 3.0 by Jurgen Appelo

Agile is a paradigm, not an instruction guide, and so all of these including the one you mentioned can be incorporated. Agile is not some stubborn point-by-point fieldbook, its a general attitude.

Many of the books I mentioned never make a single reference to Agile, because its being implemented in fields completely unrelated to software engineering (nurses doing homecare for seniors, auto part manufacturing, etc..)

https://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841

http://www.amazon.com/Visible-Ops-Handbook-Implementing-Practical/dp/0975568612 by my boss Kevin Behr and his co-authors. Also http://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509 by the same trio. In the latter the opposing factors of planned and unplanned work. Planned work, us in development would think of as stories, epics, etc in a card/wall/board centric app. Unplanned work: tickets in a incident/problem management app. You have to attend both of course, and work to minimize unplanned work. ThePhoenixProject is TheGoal but 30 years later and skewed towards IT (while still in a manufacturing company, with it's own bricks and mortar outlets), and contrasting planned and unplanned work, as I said. VisibleDevOps talks of ITIL, which ties in the "Managing IT operations" you were asking about.

this this this this this.

Scrum is not for you in this situation, /u/alookaday

Lean Startup is what you need. by Eric Ries.

You arent telling me enough. Can you describe the app a little more - I'm not willing to sign in with my google account to see more from your current description (which sounds more like you just need to change the way you are doing retrospectives). Perhaps you just need to approach the differently. 2-3 week sprints need more than 30 mins retros ...

Have you looked at some of the books on the subject?

• Agile Retrospectives
  
• Project Retrospectives
  
• Getting Value out of Retrospectives
  
  or maybe read some of the sites available:
  
  
• Retrospective Wiki
  
• Retr-o-mat
  
  Do you structure your retrospective (see the Agile Retrospective book), or put effort into planning it?
  
  Have you tried letting your team run the retrospectives? Some of the best retrospectives I've seen have been run by team members (we've pretended we've been in a Finnish Sauna with birch sticks, been on a ski jump slope, danced badly to 80s music ...)
  
  The list goes on. I havnt seen the app I admit (and I may have drunk cider at lunch), but it sounds like you are fixing the wrong problem. Experiment!

What non functional requirements? Like code quality? Tests? Performance throughput? UI/UX? What are they having a problem with?

Code quality, try the craftsman approach. Yeah we could just sling some code at it and have it done tomorrow but we are looking at this in a way to see bigger problems, 90% of codes changes is in maintenance, wouldn't be better to be a better craftsman and work on something well built instead of a hard to follow pile of garbage?

​

Tests, Quality is everyone's problem. How will we know if someone broke something if we don't have tests that prove we did it right?

​

Performance, Google has shown if an app or website has a delay of over a second people will move onto something else. Time is counted in ROI for enterprise clients as well.

​

UI/UX show them the internal metrics on how users are using the software they've worked on, better yet get them the UI complaints or NPS scores,

​

There's no I in team. he is not the team. If he is negatively affecting the teams performance he needs to be told. and shown how that is the case. Instead of adversarial try asking questions, Why do you have so much trouble with X? Look at the other teams doing it and here's the kind of results they are getting from it. If you were running the team what would you do to make things go smoother? Ok, but here's the problem with not doing story decomp. Or but the company has decided that microservices is where they are taking things.

​

Try the book Working with Difficult People there's several different types mentioned in there. People resistant to change usually need to be heard, What are they saying that you seem to not be hearing?