Agile & Scrum, SOAP, Huh?
June 26, 2012 1:10 PM   Subscribe

Agile and Scrum methodology experience...I have none but I've got my foot in the door!

Short and sweet (rewrite #3)

It's not a Project Manager job, it's a lot of what I do now, but I do not have specific experience with or knowledge of Agile and Scrum methodology experience, or a "working knowledge of web services (SOAP)". How can I (can I?) speak intelligently about these in an interview so that I can continue with this opportunity? I've googled but I need a beginner's explanation. If you were going to career day at a high school and wanted to leave the kids with a good understanding of those topics how would you explain it to them?

On paper, it's a great's just these 3 bullets.

Thanks for the lessons!
posted by doorsfan to Computers & Internet (8 answers total) 8 users marked this as a favorite
I just joined a company that uses Scrum, and it was a little bit of a change from the way I'm used to project planning, but it's really not tough to get up to speed.

The Wikipedia page on it covers the basics very well. The main difficulties I've had are forcing my mind into thinking of project deliverables in terms of User Stories and being good at determining how much work I can estimate in each Sprint.

There are a ton of online materials available on the practice, but honestly, other than terminology, it's not really too difficult to wrap your head around.
posted by xingcat at 1:21 PM on June 26, 2012

I recommend reading this book. It's a little older and it's got some real eye-rolly moments (calling people pigs and chickens; a whole irritating anecdote about how they wrote on the walls since they weren't given whiteboards), but it's where the whole thing started. It lays the entire process out clearly. Since they recommend that you try the system completely and never break the rules to start, it clearly delineates what the rules of Scrum and Agile really are, so you won't be confused by the ways in which many industries tend to change the tenets around to suit their own business.
posted by pazazygeek at 1:33 PM on June 26, 2012

I've googled but I need a beginner's explanation. If you were going to career day at a high school and wanted to leave the kids with a good understanding of those topics how would you explain it to them?

For Scrum you'll probably need to read a book about it like others have mentioned to wrap your head around it, there are some pretty specific and non-standard ways of running projects that are at the core of it. For web services and SOAP I can give you a super high level overview though.

Web services are basically an API for an application that runs on a web server. So developers writing client code somewhere else (maybe on a PC, a mobile device, or another server) can interact with the server through the web service. An example of a very common web service would be something that allows some sort of database query and returns results. The client code sends a request to the web server, and gets back a response with any results.

SOAP is a particular web service standard. It uses XML format for the messages between the server and client, and generally runs over a normal HTTP connection, which is useful for getting through firewalls. In my experience at least the SOAP implementations are heavily dependent on using libraries to automatically generate a lot of the SOAP-related boiler-plate code. So in a .NET web services client for instance the developer would just drop in the WSDL URL for the web service and Visual Studio would automatically generate all of the SOAP related code for calling that particular web service.

An example of the whole process might be for the client code to call a function like webService.FindZipCode(someAddress), which would get translated to a SOAP XML message and sent as a standard HTTP request to the web server. The web server would then parse out the details from the SOAP XML and run the FindZipCode logic, the results of which would be put in a new SOAP XML message. That new message would get back to the client and parsed out, and the client-side code would continue on doing whatever it does with the results.
posted by burnmp3s at 2:08 PM on June 26, 2012

SOAP is basically two computers talking to each other through a language called XML.

You can think of one computer acting as a web browser ("client"), and the other as a web server ("server").

The client asks for some data from the server, and the server evaluates the request, figures out what's being asked for and sends a result back to the client.

Both computers can each act as "client" and "server" at any given time, depending on how they are set up. Or, usually, one computer will be a client, issuing requests, and another computer will always be the server, handling responses.

The request and response are both structured in XML, which is a way to organize the data that both computers agree upon as the medium for exchanging questions and answers.

That's the generic description of a SOAP service. A pair of "real-world" examples of SOAP services would include getting weather updates from the US government, or looking up the dictionary definition of a word.
posted by Blazecock Pileon at 2:10 PM on June 26, 2012

For SCRUM you are either a chicken or a pig. This is how the SCRUM Master explained it: chickens are involved in producing breakfast, pigs are committed. So Program Managers and/or SCRUM Master are chickens, everyone else pigs. The Master schedules a daily 15-minute stand-up meeting, usually in a small cramped room without chairs at a crazy early time. The Master puts up big pieces of paper on the walls and gives people pens and asks them to write the items they commit to doing for the sprint. A sprint is usually a week but could be longer or shorter, its just the time period you are currently in and tracking. So you meet every day and mumble something, the Master makes updates in some web form and asks lots of questions. You are asked to track your time spent in 15-minute intervals. After a few weeks someone cries each meeting. 75% of the people develop a nervous twitch. People start to update their resumes in plain sight. The developers get together and rebel after first filling in their bathroom breaks in the time tracker and things like "thinking about butterflies." The testers are trying to do test-driven development but the developers just snarl when approached and say "No idea how I'm coding it yet, go away!" After a tense meeting with management the time tracking interval is reduced to hour units. By now many people have left or are in their 2 week notice periods. Team has a big-reorg and starts again. New manager suggests using SCRUM...
posted by meepmeow at 5:37 PM on June 26, 2012 [11 favorites]

The other end from meepmeow's example are the organizations who overlay Agile terms onto their existing culture and call it SCRUM. Weekly hour-long status meetings are now scrum meetings, the 9-month development cycle is a sprint, and so on. Nothing changes except the verbage.

Agile is the latest attempt to provide a usable, somewhat predictable process model for a nearly-unmanageable* profession. The problems with attempting to applying any process to software is that developers have a hate-hate relationship with them. They've had bad experiences in the past and hate to think how much work the next one will cost them.

At the same time, a good developer knows he needs the structure of some kind of process to guide him in priorities and deadlines** -- insofar as said priorities and deadlines aren't mere management preening. The stink of a bogus deadline is impossible to mask.

My First Law of Projects states, "An estimate ceases being being an estimate the moment it is stated." If you get involved in any aspect of project management, you'll see.

The points being thusly: a) the tool is there to serve the people not the other way around; and 2) there is no process in the world that can provide protection from management.

*Ellen Ullman wrote in Wired, "But the work of programming has remained maddeningly undefinable, some mix of mathematics, sculpting, scrupulous accounting, and wily, ingenious plumbing."
**Artists and engineers never finish projects, they merely stop working on them when external force is applied.

posted by trinity8-director at 10:53 PM on June 26, 2012 [1 favorite]

I'm back. I forgot to give you this Cheat Sheet, which I think is pretty good. There are others, but I like that one the best.

In case you don't have time to read the book, here is the highest level I can give you:

The team is comprised of three distinct roles:

* Product Owner(Or Customer): This is the person who is defining or asking for the product. "I want a website to sell my cotton candy sammiches".
* Scrum Master: This person's job is to deliver the releases at the end of the sprint as closely as possible. (In other words, they must listen to the needs of the team, get them what they want, work with the Product Owner to clarify what he/she wants, and unblock anybody on the team to help them get more productive). They also run the daily stand ups, the sprint planning meetings, and manage the burndown chart.
* Everyone Else: These are the people on the team who are responsible for completing the work they sign up for on sprint planning day.

The work is done like so:

* The Product Owner (hopefully with the help of the team and/or scrummaster) writes out the needs of the project in something called "User Stories". They are wholly end user verifiable. They do not say things like "Upload the pretty pictures of my pretty cotton candy sammiches and put them on the main page." They say things like "The user can view a picture of the cotton candy sammich immediately upon visiting the site."

* These user stories get dumped together in something called a "Backlog". Most agile organizations use a web based application to manage it (Atlassian's JIRA is very popular) - but it can easily be managed in Excel. Sometimes they are written on cards!

* The Product Owner, with the help of the Scrum Master and the team, prioritizes the backlog, putting the user stories that are most important at the top. This is purely a "I want these features more than the other features" exercise.

* The entire team is about to attack the backlog in what is called a "sprint". The product owner and scrum master will get together first and think of about how much time they need, looking at the backlog and the product needs, for a good amount of time for a sprint and when they should have a release. As a general rule, a sprint should never be shorter than 5 days and never longer than 4 weeks.

* Once the team is ready to plan a sprint, they all meet for an entire day, which is known as the very exciting sprint planning day. The entire team reviews the prioritized backlog with the product owner and the scrum master, asking for clarification on the goals of the user stories, etc. Once everybody is satisfied they understand, people start signing up for user stories. Many are cross-disciplinary and require multiple people to work on them. For example "The user can view a picture of the cotton candy sammich immediately upon visiting the site." would require a photo shoot to take the picture, the graphic designer to prepare the picture and make it web ready, and a client engineer to lay it out and put it on the front page. (This is a terrible example, since I haven't had any coffee, but I hope you are getting what I'm saying). Those team members sign up for those things as sub-tasks on a user story. THOSE are given time estimates. 2 days for the photo shoot, etc etc. Every team member keeps filling their plate up with subtasks on user stories until they are out of time for the sprint.

* In the sprint, the product owner is not allowed to mess with the team's goals in any way. I think this is probably the most important part of the entire process. The idea is, the product ownership (management) has committed to what the priorities are with the team and then they are left alone to work on them. This is how actual shit gets done in an often dysfunctional environment. Without this part, AGILE AND SCRUM ARE USELESS. I repeat, AGILE AND SCRUM ARE USELESS WITHOUT THIS PART. When the product owner comes to the team and says "Actually, I ALSO want music to play while people look at pictures of my cotton candy sammiches, and I really want to see that right now so I can show it to sales and they can get excited" - the scrum master is the one who is required to step in and tell the product manager to step off.

Please note that there are ways to negotiate extra work and changes in this process, but it's a general rule of thumb that allows the team to get their actual objectives done and actually finish a job on time. Or on time-ish. In the event that the goals of the product change so wildly that the majority of stories no longer make sense, that's when you cancel the sprint.

* Every morning the team has a "stand-up meeting". People are not supposed to sit down and get comfy. The only people that speak are the team members. The scrum master just takes notes and listens. The only things people should be talking about are what they did the day before, what they are doing today, and anything that is blocking them from meeting their sprint goals. Everything else is stand up poison and needs to get tabled for another conversation. If your stand up lasts an hour every morning you are doing it wrong.

* While the team is working, the scrum master is managing what is called a "Burn Down Chart". This shows the amount of effort the team is putting in, how much work is getting done, and how close the team is tracking to their initial estimates. This is a tool the scrum master can use to course correct. If a user story is turning out to be particularly complicated "The cotton candy keeps melting on set! We need to digitally recreate the cotton candy instead of taking live pictures. It is taking FOREVER!" The scrum master might have a meeting with the product owner where they knock a few user stories into the backlog so that the team can complete the one that took forever. Conversely, maybe things got done so quickly that things can be pulled out of the backlog and worked on before the sprint is over.

* When the sprint is complete, you have a release. The team reviews it, as well as the burn down chart, and looks at where things might have gone wrong (or right). Then they plan the next sprint. This keeps going until you release your product!

Some additional clarifications:

* The Chicken/Pig thing is deeply stupid and comes from a joke. The punchline is that a chicken and a pig are opening a restaurant, and the chicken wants to call it ham and eggs. The pig objects, saying 'you'd be involved, but I'd actually be invested!" So pigs are the people who "do the actual work" and chickens are "only involved." THIS IS A TERRIBLE METAPHOR and I don't think you should use it. Product Ownership and being a scrum master are hard, and carry a lot of responsibility. Mutual respect for eachothers work is important. Now I am just preaching, I apologize.

* There are some things that Agile is really good at when done right. Fostering team communication, keeping people focused on the actual product goals, and protecting the team from the whims of management. People tend to modify the process slightly here and there until it is unrecognizable and no longer has any of those benefits. You should ask questions about some of the major things they've changed in their process to try to sniff out if the company you're interviewing for is one of them. trinity-8-director is right about the fact that no process can protect a team from bad management, but sometimes management accepts a project like scrum because they understand it better and use it as a fail safe. Which can be great.

* Agile is HORRIBLE for long term planning, and it has no really good system for dependency management.

I will stop typing now before I write a book myself. Good luck on your interview! Also, I know nothing at all about SOAP so I can't help you there.
posted by pazazygeek at 6:07 AM on June 27, 2012 [6 favorites]

« Older How do you communicate Enterprise IT outages?   |   Help me find the perfect pen... 1000 of them! Newer »
This thread is closed to new comments.