Top products from r/agile

>Is there a book/video/training that can give me a really solid understanding of expectations of Agile?

Many. You can spend thousands of dollars and attend hundreds of hours of training. Scrum.org and ScrumAlliance.org both offer certification classes. But that is not what you need at first (unless the company pays, then do it!). The first thing you need is to understand agile is an adjective. You can look up the definition in the dictionary. If you use google though, look at the traditional definition "able to move quickly and easily", not the "project management" bullshit. Agile is not project management. Dictionary definitions are what is in common use, not what is correct, and there are a LOT of traditional managers and PMO "gurus" misusing the term. Agile is about your team/org being agile: responding to the constantly changing project & world quickly & easily.

​

Next, read the agile manifesto. The manifesto is the basic description of what the creators identified as the shared reasons their individually designed practices were successful. The actual processes they created were all customized to the creator's individual teams and situations. They all had different ways of doing things, but realized they were all successful because they all valued, for example, "Individuals and interactions over processes and tools".

​

Now, get ready to fight the PMO. I say "fight" a little facetiously though, because remember the one value I listed above? VALUE individuals and interactions. If you're "fighting", then you're not interacting very well. If management and their PMO are not on board though, you're going to have a fun time trying to merge stuff because you're going to be violating principles left & right just because they have the authority to beat you up if don't follow their processes.

​

I haven't really answered your questions yet, have I? That is because the questions you asked are a little advanced. How do you merge what the agile frameworks are recommending with management & PMO's processes, needs, and expectations? By talking with your org. By training them in the "agile metrics" and how to use them. By getting their support for the agile transition. By setting up many intermediary steps to get them comfortable and familiar with the new way of doing things. By showing them how successful one high performing team can be, and then describing the compounding benefits of getting the entire org on board so you can do that. This is stuff an experienced agile coach can help walk your org through over time.

​

So how about a couple solid answers of varying worth to your specific questions/comments?

1. "IT infrastructure is transitioning to Agile/DevOps." No they aren't. Not really. The "Dev" in "DevOps" is "Developer". The entire point of that portmanteau is to describe the merging of development & operations teams, to eliminate the problems associated with handing off the developer's work to infrastructure to install & manage. If you want a quick, semi-fun fiction style read about this, try The Phoenix Project.
   
2. "from what I have been reading, it sounds like I shouldn't be using both methodologies, but I am getting pressure from both sides to do so." It is very difficult, as I alluded to, but is not impossible. If the org is really going agile, there are going to be huge changes at the start. If not, just don't worry about it. Do whatever process they want and take it as yet another process you've "learned", without the backing values. Without management's support actually adopting the agile values, it is not a fight worth having from the trenches.
   
3. "How can I provide end deliverable dates if we are living in an Agile framework." To start, pretty much the same way you're doing things now. Sum up the estimates for all the pieces, and that is the estimate for the project. This isn't ideal and you're going to have issues. Work through them as they come up. 😀
   
4. "Should/Can I be an effective Scrum Master if I am not a developer?" Absolutely. Scrum separates the roles. In your position I'd be more worried about separating the product owner & scrum master roles. That is where you're going to get pulled in different directions. The product owner has the vision for the product, they decide & communicate to the team what to build. The scrum master is there to help the team improve their practices: identify & remove impediments, train on new practices, ensure teams are talking & healthy, etc. Finally, it is the developer's self-organizing cross-functional skills everybody must trust to get the project done... They will decide the how. Read Coaching Agile Teams, by Lyssa Adkins. As a project manager transitioning, I guarantee that book is right up your alley. That is the transition she made and can help you make. That will help you get on the right page as a scrum master.
   
5. Read whatever framework the "project" (i.e., "agile" team) is going to use (scrum, right?) They tend to be short. Just know it's a framework. It is designed for you to fill in all the gaps according to what you identified as your needs.
   
6. "Sorry I feel like I am all over the place, but it is indicative of what I am facing at work." Ya, sure sounds like it. Agile stuff is fun if you have the right Abundance Mindset.

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.

To gather insight, help teams find their own places they want to improve, and generate self-realized learning... try Agile Retrospectives: Making Good Teams Great.

Consensus driving change or driving work is all about figuring out what is the next best thing to try and improve.

If you aren't already, try capturing the outputs of your retros and have the team commit to one thing you want to make better or make great. Make this an actual backlog item and track it as you would work coming in. It should be owned by everyone, and it should be a driving force to try some actions to improve it. If you can get 1 thing agreed to by the team to improve, and then a proposed action to try as a team; you will rapidly find your pain points and make them better.

Before anything else, there's a great book that helps with this whole thing: Agile Estimating and Planning

Next, there are lots of other approaches, and based on how you're explaining your understanding on the three methods you offered (and the benchmark example especially), I think you might find some clarity in reading through these resources:

8 Agile Estimation Techniques Beyond Planning Poker - I think this will help the team wrap their heads around what's being asked in expressing estimates with storypoints.

Fast Estimation - really good technique that cuts through the noise.

Agile Project Estimation Techniques from PMI- because of your questions relating to release intervals, I think reading through this article that goes into detail about some of the techniques already mentioned may simplify your thinking on this, especially the section on "Determining Budget".


Finally, answers to your specific questions:

1. Yes, I worked with a team that did this. They had a good understanding of the needs of their qa team and were conscientious about documentation and smooth code review protocol, so that helped a lot. If something would take more than the available hours in a sprint, they'd break it down further to discrete work parts. They did move away from it after they had a better concept of capacity and velocity as expressed in story points. I think they were an exception, rather than the rule, however, and for most any other team I'd likely recommend entirely different approaches, since it's easy to get bogged down in the translation.
   
   
2. You would take a new benchmark story. Partly because as the team gets more mature, something estimated at 3pts at one point in time would now maybe be 2, and partly because effort needs to be evaluated in context, so an older work item would have staled in relevance.
   
   
3. This is more of a learning to estimate technique than one that would stay in the team's toolbox forever, maybe to get pulled out again in the future to break down particularly sticky specs/reqs. At least one of the articles above discusses this method in detail, perhaps making it easier to decide if it's worth using.

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.

The role of the product owner is a little tricky because there isn't a lot in the scrum guide that tells you how to do the tasks required. A lot of these tasks happen outside the sprint and touch on Agile Project (or product) Management and lives in the realm of Business Analysis. Of course communication with an emphasis on listening carefully is going to be the key skill.

Requirements analysis or requirements engineering is the process that you seem to be looking to define. Searching on either of those terms may prove better results for templates or techniques. That's the process of determining the user needs / wants / expectations and turning those into features.

The first step that I find important is to ensure that the PO has a clear vision of the product. By this I don't mean the details of how it will function but what is the domain the product lives in and what problems it's trying to solve, basically the why of the product.

There are several techniques that can help to define this. Some people like the Business model canvas or the lean canvas filling those even partially with stakeholders can help to define the vision.

Another technique is a version of the Product Box Game that you can do with your stakeholders to help define the features of the product. Imagine what emotional is portrayed by the box's artwork and what features are prominent on the front, what secondary features are detailed on the back.

Books that may assist are User story mapping and the techniques described in there are basically what SCRUM requires.

In the past I have also used some of the techniques in the Rational Unified Process to get a sense of the types of questions that should be asked. I don't want to put too much emphasis on that because I really don't recommend following RUP because it's way too bloated (way more than SCRUM) however, one could easily skim some of those such as the Elicit Stakeholder Requests or the idea of Capturing a Common Vocabulary can be helpful as some people use terms very differently. I don't really want to link to that because I really don't recommend that process but if someone asks I'll link it.

TL;DR check out this video, Product Owner in a Nutshell

That sounds tricky. I think you're starting with the right place: visualizing workflow;

A suggestion is that you focus on building trust by addressing pain points. What pains does the team have with the current process and can you concretely improve those in the short run (as opposed to abstractly saying "if we adopt this whole enchilada that will get better, trust me").

Another thing to focus on is measuring some of the health indicators in Accelerate. Honestly, you might be doing awesome already and the problem to be solved is recognizing and celebrating it. Good luck!

Your approach is quite interesting and brings a lot of questions and impressions, so kudos for sharing your thoughts!

> One question I have with this approach is at what point is something considered a complete "feature" and should thus produce a velocity point each iteration?

Simply put, when the "feature"'s Definition of Done is satisfied. If you have trouble defining a DoD for certain feature types, then these types might need to be clarified and/or downsized.

> What is a better name for this metric than velocity?

"Added value" seems right, considering you subtract from that metric whenever value-decreasing elements such as bugs and errors are discovered.

Now, my first concern with your approach is, like I started this reply with, that it brings a lot of questions... too many for me to consider this approach viable in the longer term.

First, such a composite metric fuses so many different variables that correlations will become undetectable... unless you measure these variables separately, which will make the composite metric irrelevant. For instance, say your "added value" suffered from an unexpected drop for a few days, one month ago. Based on your musings, this could be correlated with an acute lack of QA, a few developers on vacation, an exceptional hardware error causing hundreds of errors to be logged... anything, really. Therefore, if your metric doesn't help you investigate root causes, how will it be useful to your team?

Second, your rules related to bugs and errors make the wrongful assumption that all bugs and errors have the same impact, share the same priority and diminish your software's value equally. If your metric came to be used by management for evaluation purposes, it wouldn't fair for your team to be penalized the same for a production-crashing bug than for a typo in an administration console.

Finally, from the way you describe the metric's heuristics and their evolution, I'm afraid you'll be tempted to spend significant effort tweaking these heuristics further... that could be invested in investigating bottlenecks, researching testing tools, refining your features' Definitions of Ready and Done, etc. Say your added value is impacted way more than you expected by bugs and errors: will you consider adjusting them to -1 added value points by 5 hours of non-resolution rather than 3? Or perhaps only certain types of bugs and errors should cause these losses? What about higher-value features that could provide more than 1 added value point? Worst of all: as soon as you make one of these tweaks, your metric's past values will no longer be comparable to the revised values and your historical data will become near useless.

If you are interested by alternative approaches differing from Story Points and traditional hourly estimates, I have learned much from The Scrumban Revolution and Actionable Agile Metrics from Predicability; applying their knowledge to my previously-Scrum team brought us many benefits and improved productivity. Hope these can help you as much in return!

> By the way: scrum does not assume deadlines. They refined their wording from commitment to forecast in 2011 to make it clear that the sprint output is not based on a fixed scope.

Scrum can be done with or without deadlines. The scrum framework does not say that there should or should not be deadlines. The fact that we are forecasting does not mean that we are unable to do deadlines. It just means that we should not be accountable for getting the work done in the time we predict it will be done by because we know that work can take longer than predicted. This is why Essential Scrum proposes fixed date releases with negotiable scope.

>At the end of the sprint, it is important to have a potentially shippable solution. It is ignorant to assume that your sprints content will be done completely. If we would apply math, we would realize that missing the sprint forecast should be the normal state.

I did not say sprint contents should always be done completely. In fact, I agree that it should not always be done completely. Mike Cohn, author of Agile Estimation and Planning, recommends to complete everything that was pulled into the sprint 80% of the time. I don't see what this has to do with deadlines.

>Estimation has the same issue: we are not interested into having a number like "it takes 12h". We are interested into knowing what needs to be done and want the ability to roughly predict the future. As such maybe terms like sizing or task breakdown are better wording.

Isn't sizing some form of estimating? If one user story is a 2 and another user story is a 4, we are estimating that one of the user stories is twice as complex as the other. We don't know that it will actually be twice as complex until we get down to working on it.

Wow.

Well from the BB's perspective I totally get it. You were here during the fall, and you didn't do a lot to prevent it. so there's not a lot of points in your favor. If you're worth any salt, now that the 'problem' is removed you should be able to excel.

So let's start with a little test to gauge your knowledge: When your BB came back he had a choice to make. As you said he understands the connected methods and frameworks. you started as scrum, it crashed and burned, and he went to Kanban. Why did he pick Kanban? why didn't he just start fixing scrum?

Secondly: What is the purpose of the facilitator in an agile system? If there is one thing you look at to gauge the performance of the facilitator, what is it?

How useful you will be will be limited by your understanding of how you fit into the system, and your knowledge of the system itself.

------------

Read this book: https://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783

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

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

Hello! Have you read Esther Derby's "Agile retrospectives"?

https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649

It provides a good explanation of all the retrospective stages, as well as activities to do for each stage (in your case, the "gather data" stage). Or you could try some activities like those described in funretrospectives.com

Having said that, sometimes it is just better to talk than write. I do many of my retros on a cafeteria outside where we all sit in a table (12 people). The format is simple, no writing, we just talk one after the other (or just begin a conversation) to collect our memories and problems form the previous sprint. It is amazing how powerful that is.

Book recommendation: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

This book is not directly related to agile. But it is rather unique, because it is based on studies and not on authors subjective opinion. It tries to figure out, which mechanics are relevant for modern software development teams.

Most often our rituals are not based on evidence. They are originally based on convenience and afterwards kept up as dogma. Sadly the original introduction was often done by the wrong people.

For example agile was mostly invented by developers, but the widespread adoption of scrum was done by business people (managers as scrum master). As such a dogma was formed that may not be in the best interest of solid software engineering.

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

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!

My favorite book on Scrum is great.
https://www.amazon.com/Essential-Scrum-Practical-Addison-Wesley-Signature/dp/0137043295

This is a great read on useful metrics - https://www.amazon.com/dp/B013ZQ5TUQ

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.

I'm no statistician, but I find it hard to accept you managed to get statistically significant results from just single (1) (one) sample.

There is of course proper study that links technical and management practices to business outcomes and finds statistically significant correlations between them. See : https://services.google.com/fh/files/misc/state-of-devops-2019.pdf and companion book https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

Jeff Sutherland's book Agile: The Art of Doing Twice the Work in Half the Time is a great read for anyone that hasn't practiced Agile.

http://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X

Coaching agile teams is amazing. Once you understand the scrum processes read this book. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition https://www.amazon.ca/dp/0321637704/ref=cm_sw_r_cp_api_i_yRv3DbZ9B4YY5

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

Can't express how good this one is. Overall, any of Mike cohn' books are all great

https://www.amazon.com/dp/0131479415/ref=cm_sw_r_cp_awdb_t1_scbOAbVTE20NV

Edit: user stories applied is another one of his greats:

https://www.amazon.com/dp/0321205685/ref=cm_sw_r_cp_awdb_t1_WdbOAbZP5TPTC

I liked The Art of Agile Development by James Shore and User Stories Applied by Mike Cohn.

Jeff Patton's Story Mapping, even though it seems more limited from the title, is probably the best introduction on _how_ to do the job.

I would highly recommend Coaching Agile Teams by Lyssa Adkins

Pens and post its work.


This book gives you hundreds of actionable opportunities based on the audience: https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649

The Phoenix Project is probably the best book out there - I also recommend: https://smile.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/ref=sr_1_3?s=books&ie=UTF8&qid=1520447802&sr=1-3&keywords=Agile+Retrospectives

Because retros are hard to do right and awful when done wrong.

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

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

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

I reccomend that you read this and follow his blog too, he's written extensively for this subject amongst others

User Stories Applied: For Agile Software Development (Addison-Wesley Signature) https://www.amazon.co.uk/dp/0321205685/ref=cm_sw_r_cp_apa_i_09mQCb22J357P

this this this this this.

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

Lean Startup is what you need. by Eric Ries.

LEAN Software Development by Mary and Tom Poppendiek
https://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783

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.

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.