Timeboxes in Agile Meetups

As I dive deeper into the Agile world and continue learning I’ve been going to meetups one to two times a week.  I found a few groups on meetup.com and have attended lots of meetups to learn, help, and network where I can.

For the uninitiated I thought I’d just publish what the experience typically looks like there in case you were interested in coming, but didn’t really know what to expect.  Depending on the size of the group they will break the group up into smaller groups to facilitate more in depth conversations, usually in size from 5-9 people.  This of course is in line with the recommendation of Scrum where dev team sizes are anywhere from 3-9.  Any smaller and there wouldn’t be that much collaboration and any bigger there are obviously too many to really cover as many topics as the group would like and some people are more apt to not comment if they’re in a group that is too small or too big so this helps solve that problem.  Note that this same thing could and ought to observed in your own organization.

From here you’ll take roll and then in your group you’ll be asked to write down things you’d like to talk about.  These can be anything from how to manage problems in the team, duties of a product owner/scrum master, types of software used to track project progress to which certifications are the most relevant or not to get to excel in your role.  Then you yourself get 3 or 4 votes and you’ll mark which sticky notes you want to talk about with your votes. 

The highest voted topics are discussed first and a timebox is given of anywhere from 5 – 8 minutes.  When the timer goes off the group is asked if they’d like to continue, maybe they’d like to continue, or would not like to continue.  This is done by thumbs up, thumbs sideways, or thumbs down.

Now you know what to expect at most meetups.  Others will also include a guest speaker(s) or perhaps a presentation on the company hosting the meetup along with split out group discussions. 

What are your most effective ways to holding meetings and learning and networking?

My experience on agile teams

Someone asked me the other day what my experience on agile scrum teams has been like so I thought I'd write it out here as well.

Some of the teams that I’ve been on are much more structured than others when it comes to agile scrum implementation and use.  My most recent stint was at MasterControl where they did a pretty good job of it and are actively implementing SAFe right now.  When I first started there a couple months into it we all went to a big house in summit county (Park City area for those who don’t know where that it is) and we holed up there with tons of goodies and what not to plan out upcoming projects and things we were going to improve on in the coming year.  Essentially this was like a BIG sprint retrospective where you identify one or more things to do in the upcoming sprint (year) that will improve the overall efficiency of the dev team and for our stakeholders. 

Once we were back we went to work on those things.  My team worked on a 2 week sprint time frame.  We used workfront to track our projects, which were estimated by hours.  We met every week on Monday to talk through progress of each project, any impediments, and renegotiated what was to be done next or what needed some changes on the existing projects. 

Every day we held a daily standup to talk about what we’d worked on the day previous, what we were working on that day, and any impediments or items that were a dependency from somewhere else.  Afterwards the project managers could and would check in with other teams and the dev team/person assigned to a project to get a status update and help in removing said project along.

This was the bulk of my experience in our agile scrum teams with little nuances here and there with MasterControl.

Why Scrum?

What is Scrum and why use it?

Scrum is a way, a framework, to complete projects.  These honestly can be any kind of project that you’re working on from simple to complex.  It was created as a framework to push out complex projects.  Before scrum they were just projects and done in a linear fashion and once the project was finished it was pushed out to the public in the form of a service or product.  Certainly there are variations on this, but that is the general gist of how projects went.  Nowadays this method of dreaming up a project or product and doing the entire thing and releasing it once it is done is called the waterfall methodology. 

Basically you do all of one thing before moving on to the next thing.  While this is nice sometimes for the customer it has its pros and cons. 

Agile allows for rapid iteration on a product.  It also limits time to work on a particular part of a project to a set short period of time.  This allows for trying things quickly and getting them out quickly.  The last thing you want in a product is something that isn’t needed in the marketplace anymore.  Also I feel like the agile method lends itself to more emotional wins within the team that is actually working on the product. 

If a team is assigned to work on the product at hand and they miss their waterfall deadline of having it out the door after 6 months vs 2 weeks for the next most valuable thing in agile, then it just feels like a bigger problem though theoretically it is possible to do potentially the same amount of work in the same amount of time.

What do you think of scrum vs waterfall methodology?