Reddit reviews Succeeding with Agile: Software Development Using Scrum

If you're interested in Scrum (it's not an acronym) then an easy way to get started is to take training as a CSM (Certified Scrum Master). It's a 2-day course with a fairly easy multiple-choice exam.

If you're already a Product Manager, you could also look at the CSPO (Certified Scrum Product Owner) which will help you understand the differences in the way requirements are treated.

Scrum isn't the be-all and end-all of Agile methods, so do keep your mind open after the training! But it will help you to get your foot in the door.

After that, try looking for local Agile or Scrum groups; most big cities have them. Look out for Agile conferences too; even if you can't make it, a lot of them post the talks online.

If you do end up as a PM and you're struggling to understand something, don't be afraid to hire an Agile Coach for a few days. They'll help to mentor you, explain how Agile works, and fine-tune your processes.

The most important thing to remember about Agile methods is that they're there to help handle uncertainty. For anything you do that's new, and you've never done before, it's useful to make discoveries early rather than later and to get feedback quickly on those discoveries. In Waterfall we made sure we we're getting it right. In Agile, we assume we can't know everything up front and will inevitably get some of it wrong.

I'd also be remiss if I didn't mention Kanban, which is related to Agile and originally derived from the Lean techniques used at Toyota, and Cynefin (my blog, the Wikipedia page is also good). Mike Cohn's books are a pretty good first stop for basic Scrum, but Kanban and Cynefin will help you to see beyond that.

Finally, if you get stuck, http://pm.stackexchange.com is your friend. You can also shout out on Twitter; there's always people willing to help and pass you links and ideas.

(Oh, and don't worry too much about the formality. I work as a Lean / Kanban and Agile consultant, have no formal qualifications in it, and am internationally recognized. Doing it and having the metrics and stories to show that you've done it is more important than a qualification.)

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

Read these books to get to grips with the latest techniques and ways of working. As an employer I'd be extremely impressed if you'd read these books. They will give you a big head start when trying to move into the professional work environment. Most of them will apply to any programming language but they mainly use Java as the example language but it's very similar to C#. It's books like these that are the difference between a beginner and an expert, but don't forget when you start coding 9-5 with good developers you will very quickly pick things up. We were all in your position at one point, if you get these read it'll all be worth it in the end!

Coding

C# in depth - I've not read this one since I do Java but I've just had a quick glance. This should be pretty useful and it's a respected publisher. I think you should start with this one.

Clean Code - Great book which explains how to write clean concise code, this 1,000,000x. It doesn't matter what language you are using it should apply where ever you write code.

Cleaner Coder - Another Robert Martin book, this one is easy to read and quite short, it's all about conducting yourself in a professional manner when you are coding. Estimating time, working with co-workers, etc.. Another good read.

Growing Object-Oriented Software - This book is about writing code using test driven development. It explains the ideas and methodologies and then has a large example of a project that you build with TDD. I just read this recently and it is really good.

Head first design patterns - This book goes through essential design patterns when coding with an object orientated language. Another essential read. Very easy to read, lots of diagrams so no excuses to not read it!

Work Methodologys

Kanban

Succeeding with Agile


p.s

Start building stuff, get an account on linked in and state the languages you are working with. This will help as well because having something to show an employer is priceless.

It depends if you're looking for project management or people management.

For the former, I would suggest "Succeeding With Agile"

http://www.amazon.com/gp/aw/d/0321579364?pc_redir=1406197128&robot_redir=1