Gist Series – Methodologies: Agile, Scrum, and Waterfall

The Gist series came about from a Senior Design course I’m teaching as an adjunct at the University of Minnesota’s Computer Science department for the 2016-2017 academic year. The focus on that course is to have the team of students design and build a software project while partnering with an industry partner, in our case Microsoft. Just like in my day job, I’m there to assist them through technical and product evolution through leadership and it also offers me a chance to give back to my alma mater. One of the areas where I’m trying to do that is with a ‘real world’ lesson. I plan to take a topic and present a concise take on it. Thus far they’ve been in the top-down academic paradigm which tend to over-formalize processes that they’ll see soon as software engineers. My aim is to help them see that all the theory gets molded and formed for the environment it lives in as well as to respond to fast moving topics that move too quickly for typical curriculum.
Because we are going to use Scrum as our process it seemed the ideal first topic.

What is Agile about?

This deals with the development methodologies. The traditional is waterfall which is a sequential top-down process. And you go down, you don’t go back up…just like a waterfall. Waterfall has been around forever and it does work. Some of the best examples (and worst too) have been with defense software projects. The keys to having success is to be really solid in requirements gathering and being able to effectively lock in the design. However, waterfall often failed leading to really bad anecdotes about development but really good books like the Mythical Man Month. The main reasons it would fail is that requirements typically change. Either the stakeholders want something else because of something unknown or because now that they see it working it matches what they said but not what they meant; often its too late to effectively veer so changes are expensive, deployments don’t always feel like a victory, and folks may be left grumpy. Plus a project can be years long and not all resources are effectively leveraged. I remember a project I was asked to work on for a bank conversion where requirements was going to take 6 months and I asked what the 70 person team of developers would be doing in that time and I was told I would develop a training program for them until the requirements where done. Whoa…outside the scope of normal but true story.

So What is Agile.

To me, Agile is an adaptive, iterative methodology that focus on getting feedback quickly (fail fast for the startup school folks out there) and prioritizes communication over the upfront complete requirements gathering of waterfall. You do this by focusing on smaller chunks of work, typically 2 or 4 week sprints, and can effectively veer based on outcomes that show themselves. These are my words, google can help you find exactness. With agile, specifically scrum, the team is more of a team. The product owner is consistently communicating with the developers so days/weeks aren’t going by with lingering questions or unknowns being left unanswered. Buy in with the team is much higher in my experience because the team should be heavily leveraged in sprint planning by determining cost/risk as well as priority of features to the project. Additionally, communication is key and daily standup’s help foster that team communication. Because the team in constantly checking in with what they’ve done, plan to do, and what they’re hung up on problems are resolved much faster and that brings faster delivery of features. This can be measured with velocity.

Why Does this Matter

This matters because you’re going to work in one or the other process or a mashup of the two or a frakenscrumfall. Either way, in the least its good to know what to expect if you’re ambivalent. Secondly, if you care, then you can look for a workplace that employs the process you most align with. Most newbies think the key to their job satisfaction is the tech stack, the perks, and/or the pay. I tend to find that job satisfactions comes down to your boss and the way the team interacts, oh, and if you have Nerf wars! I miss that job. Lastly, if you don’t have an opinion I really don’t want to work with you. Do you know how boring it is to ask intelligent engineers what they think about something and then hear crickets?

Some Other Common Questions

So what sucks about scrum?

People generally make anything that sucks suck. Agile has very specific roles and responsibilities and they are crucial to success. The biggest is the scrum master who is like the project manager in a waterfall scenario. The scrum master has to keep the sprint running smoothly by facilitating the communication between the product owner and the developers that we’ve mentioned is key. They also have a fair bit of administrative work in tracking the sprints versus the overall project. For this role I really like detail-oriented folks who like organizing folks, in my experience a kick-ass project manager will be a kick-ass scrum master.
The product owner is also a key role as they must have their act together with the stories. The stories are the requirements so they need to write them with that in mind, or have some help from a BA type of person. The dev team also has to learn to be involved and to try to get away from the ambivalent tech gloom vibe that some team members can bring. After a few months they’ll hopefully learn from the rest of the team or figure out they don’t like process enough to find a new home.
What generally doesn’t work but is often attempted at smaller shops is to part-time these roles. If you’re moving to scrum then have the person filling the key roles have a majority of there time spent working in that role. I’ve had scrum masters that only kickoff the stand-ups and don’t do anything else. #thanks #facepalm #supposeyouwantaraise

How do we build something large though?

Scrum can totally be used, Google search can again back me up here. I’m not really covering Scrum per se, just hitting it quick. Stories live on the product backlog and larger stories are called epics. Epics can be contained on a product road map which shows the major features and phases of a specific products. So you can plan out our product for years. That’s part of what I do and I have a road map for each of our major products as well as our tech infrastructure which feeds into the backlog where specific product owners go and add their magic before it goes into the sprint and then gets D-O-N-E.

What tools do you use?

I have a strong view on tools in that they really don’t matter as much as being consistent with whatever tool you have. That being said, from my statements above I must be opinionated, and I am, so I lean towards tools that follow Occam’s razor. I’ve had folks that like to write stories in Drive docs and then copy them to the scrum tool of the moment. If that works for them then awesome sauce but I just prefer to write the story once, in the place where it will be consumed. I prefer to use Trello over Jira because its simpler. For road maps I prefer Drive sheets over SaaS based road map tooling but in the end whatever the team wants is fine by me.

What if someone doesn’t like it?

There are always engineers who don’t like change or can nitpick a methodology to death. You know what, odds are if you do waterfall they will have the same view. Additionally, I’m willing to wager that if you offer this fictional representation of a developer the chance to develop the best methodology that they will pass because they don’t actually care. What’s great about scrum is you can make it light and flexible or as big and heavy as you see fit.

I’m really a kick ass coder and I want to be left alone

I feel you! I used to think like that then I learned I liked sunshine, people, and puppies. Seriously though, this stuff is everywhere so if you have a tough time working with folks you should maybe be a professional widget maker at home or get a gig with fsociety.

Where’s your pictures showing the methodologies that I see in all the good posts?

Who said good post? Anyway, they are only a click away.Here you go!

To PMO, or Not to PMO; That is the Question «

This post from Cornerstone Advisors blog regarding PMO caught my eye last March. I had set it aside to go deeper on my thoughts of what is and isn’t a mature PMO organization but am going to table that for now. I will say that PMO is much like engineering in that not having the Steve Jobs “A” players will come back to bite you. A great PM and PMO office will save you greatly and a poor PM and PMO office will cost you dearly.

To PMO, or Not to PMO; That is the Question «