(Part 2) Best products from r/agile

I apologize in advance for the long post: Thanks so much for all the help and feedback everyone! I will definitely try to utilize everyone's advice as best I can. Here is my game plan for the next few months. I would love more feedback if everyone is willing to help refine my process.


1- After talking to my aunt/mentor in the field, she recommends that I should not go for the CSM *until* I have a working understanding of the field I will be getting into. She recommends that I apply/learn as much as I can about Project Management Essentials like the one she took in UChicago. Unfortunately, the next class that is offered is Jan 16th, and I personally want to leave the hell that is my job as soon as possible.

To get over this, I have decided to learn as much as I can on my own from books like A, B, C, D, E (please take a look at recommend if there are others I should look into or if I should drop any). She recommends that I do not focus on just Agile but also Waterfall (a basic understanding). I will also be utilizing the podcasts and links graciously provided by u/recycledcoder:

"So... podcasts. There are many, but these are my faves:

• Agile for humans
  
• Scrum Master Toolbox
  
• Agile uprising
  
  And finally, my own preferred twist on it all: Modern Agile"
  
  
  2- Once I have done as much research on the fundamentals as I can before October 13 (not a lot of time, I know), I will be attempting the CSM boot-camp course. I want to do this because I have no prior experience in field, and while I know a certification may not mean much, I hope it reflects my desire to start applying for roles for project coordinator positions. I will have to tweak my resume to show my desire, and I think the certification is the first step to do this. I'm favoring the CSM over the PSM and PSPO per u/nizzerp and my aunt's advice as these courses need more experience to apply for.
  
  ​
  
  

3. I know several technical recruiters and I think the best step for now would be for me to reach out to them (thanks u/zappafield) and see what temporary/contract positions I can build up in the meantime. I think that with enough short term positions in different environments I will be able to best get a full scope of the field I am getting into.
   
   ​
   
   
4. While I am still stuck in the hell of trying to get a company to let me on a/any project, I will be going on meetup.com (thanks u/Curtis_75706 and u/zappafield for the idea) to better immerse myself in what I am hoping to get into. Also will be trying to bolster my credentials with MOOCs (per u/kmolch) with any recommendations you wonderful people may have. I am definitely interested in the Business Analysis route they had mentioned.
   
   ​
   
   I know there are a lot of links and stuff, but I would really appreciate it if I could get as much feedback as I can to start committing to this plan, especially feedback on books and resources in my step 1.

Some additional information can help a lot in recommendations. I'd like to know the following:

What is your team size?

Is your team co-located (all in one place)?

Can you describe the type and flow of your work?

Do you have open channels of communication with your customer, and if not, do you have people who can stand in and more or less speak for the customer?

Do you think the leadership would be on board for a drastic change?

It is unlikely that the visibility and continuous improvement of an agile framework will not bring about significant improvements within your company. Also, if you are the type that thrives on facilitating a team and helping them grow to excellence, then this will be a great career change. Personally, I love my job and enjoy every day. With the above simple questions answered, it would be a lot easier to spark a conversation.

Jeff Southerland's book (already mentioned) is a great intro for Scrum, and not a boring read. I also like David Anderson's Kanban, if you have a more steady continuous workflow like a compliance or support team, this can fit better. Also, a good read. The Scrum Guide is rather short and is the definitive guide for the Scrum framework. Exactly how you execute under that framework is largely up to the team, but everything is based on the idea of iterative continuous improvement. Once you get this idea down in practice, you'll be hooked.

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.

There is a really great solution that works great when it is politically practical: fold the dev and QA team together and tell them that they own releasing a quality product. That is the only real fix I've seen.

If you are stuck with separate teams, then I have two pieces of advice...

First, stop tracking anything that is per-discipline; only track "feature is ready for release/not ready". The reality is that "dev complete" is not a useful state from the business perspective, so just stop tracking it. Your devs will likely resist this because they have been getting rewarded for "dev complete" even when it's crappy quality. You want them thinking about optimizing the "dev + QA" time, not purely the dev time.

Second, start doing bug categorization. I wrote up how I did it here. I had *amazing* luck with the first team I did this with and it was a team with separate dev/qa roles; my devs felt that having "foreseeable" bugs come up in the feature they worked on was a pride thing. I don't remember the numbers, but merely by reporting the stats monthly at the end of an iteration, they went from 45 foreseeable bugs in the first month to 4 foreseeable bugs 4 months later, and that was with me expanding the definition of foreseeable along the way. It drove dev/qa discussions in a way I have never seen elsewhere and pulled in our product owners in a very agile way as well.

I also recommend that you go read "The Goal" by Goldratt as it provides some insight into optimization across groups (others recommend "The Phoenix Project" as that's IT-based, but I think "The Goal" is a better choice).

I also wrote a blog series on applying the theory of constraints to software; you can find it here. Read from the bottom up.

I read some books people here recommended and they were insightful. I was at another "agile shop" even more recently and noticed the difference between experienced business people who promote Agile like the idea of it and that's cool, in theory. Probably could be cool. So I'll say it's not a total scam.

EDIT: Here's the book /u/kida24 recommended which I'm glad they did. It was quite eye-opening in how Agile can work for some industries. https://www.amazon.com/Age-Agile-Smart-Companies-Transforming/dp/0814439098/

It's just the Bible thumpers like you said who ramble on about it. It's a waste of my time as a designer, and it's interesting that when I freelance contract at a place— even for months or years— I'm always asked to do my work outside of Agile as I'm paid by the hour to produce, so me attending Scrum or Points or whatever is a waste of productivity and dollars. They would be hiring someone basically to work part-time and paid full-time.

What was it Hemingway said? "Don't confuse movement for action."

You should definitely read this book: The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win.

It's very fun to read and talks about a business transformation with DevOps / Agile.

The questions you ask are answered in the book.

​

Cheers, Johan

(Experience: PMP, PMI-ACP, CSM, ICP-ACC)

I'm a project manager, with a CSM. I found getting my PMI Agile Certified Practitioner certification was really useful. Mike Griffiths helped create the certification and synthesized a lot of the books people talked about in his PMI-ACP prep guide: https://www.amazon.ca/PMI-ACP-Exam-Prep-Mike-Griffiths/dp/1932735984&ved=2ahUKEwjfz5KB56beAhULrFMKHXQIAMgQFjAKegQIBRAB&usg=AOvVaw3aObnbeD41xQUmqJuXsuWe

This book gave me a good breadth of knowledge in Agile.

in terms of websites, I turn to infoq's agile section and Mountain Goat Software.

Have you looked to see if there are agile meetups in your area? Or an agile conference that you can attend? Having an agile mentor/coach is really helpful!

Manifesto here..

http://agilemanifesto.org not the finest looking site but key points covered.

https://www.scrum.org good place to start, scrum is just a flavour of Agile

Main thing though is mindset, once people buy in it becomes much easier

Scrum - A Pocket Guide (Best Practice (Van Haren Publishing)) - place to start Scrum dive

and I like this one https://www.amazon.co.uk/dp/B00UOYB2N6/

> 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."

If you are interested in Scrum, I'd recommend reading Software in 30 days and/or Scrum, the art of doing twice the work in half the time or at the very least, read the Scrum Guide. For agile in a larger sense, there are plenty of good books, like The Art of Agile Development or Agile with GUTS

Iirc https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 was a pretty good book and gave lots of hints on how to refactor legacy code to make it easier to replace. Been a while since I've read it though.

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!

This one was pretty clear and easy to follow

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

For staying on track, we use this: https://smile.amazon.com/Time-Timer-Original-Optional-Management/dp/B002GTZZ6M/ref=sr_1_4?ie=UTF8&qid=1521158440&sr=8-4&keywords=timer+clock

Having some big, obvious, and physical is much better than a timer app.

As the for the rest - what is your interested in tracking statistics? Is it not enough to just say "our meetings are unproductive" at retro and dig in from there?

I really enjoyed "Kanban" by David J Anderson. https://www.amazon.com/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402

https://smile.amazon.com/dp/193796504X/ref=cm_sw_r_cp_awdb_t1_Q4ZjDbQJ3XY23

We used Kanban to sort out publishing production. It was not “agile” really it was “lean”.

Map your process and tasks flow through the process.

Read David Anderson’s book

https://www.amazon.ca/dp/0984521402/ref=cm_sw_r_cp_awdb_t1_IaJ-Bb394Y1FH

https://www.amazon.com/Age-Agile-Smart-Companies-Transforming/dp/0814439098/

Scrum doesn't have failed stories, anything that doesn't get accepted by the PO is not counted against velocity, especially if it's been abandoned entirely. I've used TFS for scrum, but based on your type of work, the fact that you are running 1-week sprints (rarely recommended) and that you are tracking velocity/capacity per person rather than your team (also very rarely recommended) I would make the switch to Kanban, specifically operational Kanban detailed in David Anderson's Kanban bluebook:

​

https://www.amazon.com/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402/ref=sr_1_3?crid=3R9PO4NATTFZT

​

You will then change what you are tracking to concentrate on flow control (with cycle times per class of service, etc.) rather than worrying about velocity.