Quickest way to fake like I know Agile

[Grey Smith]

Hi,
I just started a job which is evidently all about Agile -- there are daily "scrum" meetings, big boards with post-its on them which keep getting moved around and talked about, and someone who seems to be like a TicketMaster who gives everyone tickets to do. I've seen "story points" and other bizarre terms, and I'm sick of the phrase "as a user" already. I'm not really sure what's going on; no one has explained anything to me and I consider it too dangerous to admit my ignorance to everyone. (There is no private space at work and hence I can't speak to anyone in private. I find it a very chilling environment.) How can I fake like I know what's going on without having to read a whole book about it? (reading is not billable hours..) I'd rather focus on programming and not "Agile" and a bunch of other "tools" which seem to get in the way of me getting any actual programming done.
Hope you can provide a summary.
Thanks!

[Jeanne Boyarsky]

The official Scrum guide is a pretty short read. It will give you a feel for what is going on. I do recommend talking to a teammate. Everyone does Scrum differently and it is important to know what your shop is doing. Can you have lunch with a teammate outside the office? That's more private.

Not to be blunt, but...
If you believe that Agile is getting in the way of coding, you are a hinderance to your team. You really should read a book like "Learning Agile" to understand why they are doing agile and why it isn't a waste of time. Similarly, faking knowledge is also a hinderance to your team.

[Grey Smith]

Thanks for the link. I'll read over it.
I don't mean to hinder anyone, and I do mean to do a good job. I can put aside how I feel about a particular corporate policy or process and work within its bounds, but when I'm not at work I don't have to act like I like it. I am sorry if I offended you. I acknowledge off the bat I don't know much about Agile, and that I wouldn't be posting if I didn't want to know at least a bit. (and where better to learn from than here where I can at least be honest?) If I felt secure that I would not be judged at work I would ask far more questions there, and probably do much better, but I've had enough bad work experiences to not be so trusting.

[fred rosenberger]

Grey Smith wrote: I'd rather focus on programming and not "Agile" and a bunch of other "tools" which seem to get in the way of me getting any actual programming done.

You do understand that programming is really 90% thinking, and only 10% typing, right? Agile is a tool that helps you think through what your application needs to do. And any manager worth their salt is going to prefer you ask questions sooner rather than later. Imagine if six months goes by and you boss then finds out you don't understand the process you've allegedly been following...

[Andrew Stellman]

Instead of faking like you know agile, how about actually knowing agile? That's exactly why Jenny and I wrote Learning Agile.

Most of the folks here on JavaRanch are familiar with Head First Java, right? We wrote two books in the Head First series (about C# and the PMP exam), and from that experience we learned a lot about how to make material stick in your brain. We worked really hard to write Learning Agile in a way that makes agile very easy to learn, using many of the same techniques that make Head First Java and the other Head First books such effective learning tools.

We actually talk about this in the first chapter, which you can download for free from the book's O'Reilly catalog page: http://shop.oreilly.com/product/0636920025849.do

[Junilu Lacar]

Grey Smith wrote:I'd rather focus on programming and not "Agile" and a bunch of other "tools" which seem to get in the way of me getting any actual programming done.

I'm going to take a different tack on this: Yes, this is a hindrance but I will stop short of saying *you* are a hindrance because of this perception. Let's explore this a little bit with some probing questions:

1. In what way(s) have the agile practices/tools your team uses gotten in the way of you doing programming?
2. Have you brought up this concern in any of the daily stand-up meetings?
3. Since you have admitted ignorance to these practices/tools, what have you done to get a better understanding of them? And by "understanding" I mean knowing *why* you do things rather than what to do and how to do it.
4. Does the team have technical practices that promote agility such as Test-Driven Development, Pair Programming, Continuous Integration, Refactoring, etc.? Do you follow any of these agile technical practices regardless of whether or not the team does?

[Jeanne Boyarsky]

Grey Smith wrote:I can put aside how I feel about a particular corporate policy or process and work within its bounds, but when I'm not at work I don't have to act like I like it. I am sorry if I offended you

You didn't offend me. You aren't on my team .

I was reacting to the supposition that learning agile is a waste of time. The word "fake" in particular.

[Grey Smith]

Fred -- Yes, I agree that programming is 90 % thinking. I'm surprised at how many people don't realize that. However, it is news to me if Agile does help anyone program. It seems a mass of status reports and paperwork (mostly on the computer, but same difference), and short meetings which rarely focus on any details or bring up different points of view.
I don't feel that I need a tool to tell me what the application needs to do. I think that common sense, and talking it over with whoever designed the app and the other people on the team (on a regular basis), can do that job. I know that applications should have as few bugs as possible and be easy to use and maintain. Sometimes figuring out how to make that happen is hard, and on a team it's important to pick a good strategy and have everyone stick by it.
I agree that good communication is important. I'm not going to straight up lie about not knowing something. I'm just not going to volunteer something that might make me appear less competent when I'm new at work. Just not smart to do that -- I don't think anyone can fault me for wanting to keep a job. My judgment of humanity is that we are unfairly judgmental towards other people ( ;) ), and I do not want to be judged.

Andrew -- I read the 16-page Scrum book Jeanne linked to. To me, how ideas are implemented are far more important that what they are in the abstract. Agile and other systems might sound great or awful in the abstract, but what really matters is how people actually use them. I don't put any stock in abstractions, buzzwords, corporate philosophies, etc., because most of the time they don't affect what actually happens day-to-day. Just a bunch of pretty words to dress something up. I have simple ideas about what makes a good workplace and a productive workplace -- open communication (which has to come from the top first as a sign of good faith), committed workers, and a willingness to talk about and accept criticism are three things that come to mind.
I'll glance over at the first chapter. And -- this is a promise -- if I do win a book copy I will read the whole thing.

Junilu --
1) Hm. It's a bit hard for me to separate out company practices and the Agile system since it wasn't explained to me. I feel like we rely too much on applications and virtual documents that are scattered in many places and all have their own logic about them. Learning them all has taken a good deal of time, and I think the tools are too specialized for the work I will be doing. It doesn't seem like there's much freedom yet in the ticket system -- that is, if say one bug is hiding three others, or if a bug and a bunch of other bugs are best dealt with by refactoring a large block of code, I'm uncertain that that would fit neatly in and be accepted. I also think that it's very hard to predict how long some problems will take, and that makes it difficult to be very definite about what will be done in a certain block of time. It's of course necessary to make predictions about what can get done, and without some kind of goal or deadline it'd be too easy for many people to slack off, so I can understand the necessity of structure.
2) …. I'm the new guy. No. Generally even if I don't like something, I won't say it until I'm completely sure about it, because rushing to judgment is very often a stupid thing to do. I'll still rush to judgment in my head, but I'll hold off on saying anything until I'm very sure, 'cause I know I could be wrong. And in the workplace I'm not going to say anything that's going to get anyone upset, unless there's really no choice and it's part of my job to do it.
3) I read the Scrum guide. I also do my best to understand all the tools and systems I'm supposed to use -- read the tutorials if I have time, or listen if someone is willing to explain it, or google it if I need to. Why I do things -- not exactly sure what you mean. I am at work to do what my boss says. That is what most jobs come down to. If you get really lucky then the job is mostly about doing a job, but that's only if your boss is a good boss and supports you in what you have to do instead of getting in the way. I get the feeling that programming is supposed to be professional job where there's lot of velvet on top of the you-are-at-work-to-do-what-your-boss-says, but really, that's what almost everything is.
I'm not trying to slink or be lazy or anything -- I really would like to do a good job.
4) No TDD -- I almost wish there was though because testing and documentation are an afterthought at best. I know there's supposed to be "continuous integration," which if I understand it right (working to produce software that is incrementally better and more functional) seems like common sense to me. Of course you should run your code all the time to make sure it works; it's nice to do tests on it all the time; and it's easier to fix bugs right when they come up -- so you should always strive for a working piece of software so that you know that your code does what you want it to do. Refactoring -- that might have a different meaning in the Agile world. To me it just means improving code that you already have and that already more-or-less works by doing things like adding documentation, making function/variable names more understandable, getting rid of repetitive code, making code more readable, creating new functions/classes to compartmentalize code better and make it easier to add functions/features or fix bugs, etc. I'm totally behind refactoring and when making a project bigger you have to do it on a continuous basis. Another benefit to refactoring is that you become more familiar with the code base, which makes it easier to use it effectively when adding features.

Jeanne -- Well, I really did owe you more courtesy. Even if I do doubt abstract corporate philosophies, I could have been a bit nicer to someone who thinks the opposite of how I do.

[Andrew Stellman]

Andrew -- I read the 16-page Scrum book Jeanne linked to. To me, how ideas are implemented are far more important that what they are in the abstract. Agile and other systems might sound great or awful in the abstract, but what really matters is how people actually use them. I don't put any stock in abstractions, buzzwords, corporate philosophies, etc., because most of the time they don't affect what actually happens day-to-day. Just a bunch of pretty words to dress something up. I have simple ideas about what makes a good workplace and a productive workplace -- open communication (which has to come from the top first as a sign of good faith), committed workers, and a willingness to talk about and accept criticism are three things that come to mind.

This is an excellent attitude to take when learning about agile. If something doesn't work in real life on real projects with real people, it's not worth doing.

One thing about not putting stock corporate philosophies, though. An important part of agile is the idea that values and principles have a very real effect on how well you and your team run your project and build code.

Have another look at the agile manifesto, and especially the principles of agile software. It's really easy to dismiss this as vacuous bullshit. It's not. These are real, practical ideas, and they come into play every single day on an effective agile team.

Jenny and I make that case in a very simple way in the first chapter of Learning Agile, showing how the most common practice for agile teams -- a daily standup meeting -- can be much more (or less) effective depending on the attitude taken by the people who are doing it.

One other thing about the Scrum guide. You can follow absolutely everything in it and get good results. But some teams get truly astonishing results from Scrum while others only seem to get moderate results, even though they're doing the same thing. One of my favorite quotes is from Ken Schwaber, one of the creators of Scrum, in his book Agile Project Management with Scrum:

For Scrum to work, the team has to deeply and viscerally understand collective commitment and self-organization. Scrum’s theory, practices, and rules are easy to grasp intel‐ lectually. But until a group of individuals has made a collective commitment to deliver something tangible in a fixed amount of time, those individuals probably don’t get Scrum. When the team members stop acting as many and adopt and commit to a common purpose, the team becomes capable of self-organization and can quickly cut through complexity and produce actionable plans.

I added the boldface to that quote to highlight the big difference between a team that is getting some improvement from following Scrum (what we call better-than-not-doing-it results) and one that gets truly astonishing results. The Scrum Guide talks about teams being self-organizing, but it doesn't really tell you how to get there. That's not what it's there for, any more than a Java textbook is going to tell you how to be a better programmer.

I haven't even talked about the Scrum values, and how they have a huge impact on how well a team does with Scrum--but only if every person on the team understands and takes those values seriously, and doesn't dismiss values (like courage, openness, focus, commitment, and respect) as just more corporate philosophy BS. If they take those things seriously, they will get much better results on real projects.

I really hope you get a chance to read Learning Agile. I would love to hear what you think of it.