entrepreneurship, Experience, Experiment, Failing, Focus, hackathon, hustle, Improvement, IT, Learning Lessons, Technology, Trying, Zoning

Why Hackathons Are Awesome: Hacking Detroit’s Zoning Code

For the last two months, I participated in a monthly hackathon event called the Detroit Civic Hackathon (next one is November 12!). These were the first two installments of what is becoming a monthly event that originated from a monthly happy hour meet up called The Detroit Urban Tech Meetup.

These past two events were great! The past few days I reflected on why these two hackathons were awesome.

Focus On Your Passion

First, hackathons are awesome because they enable a large amount of dedicated focus. In my day-to-day work, I do not spend more than 2-4 hours focused on something, unless I am working outside of the normal 9-5 business hours – I get interrupted way to often. Hackathon’s are special because they allow you to block out the world and spend deliberate time working on whatever problem you are trying to solve.

In addition, hackathons harness this focus on your passion. For me, I am passionate about learning new technology and cities. In this case, I am learning JavaScript and the React library and trying to understand/solve a problem related to city zoning (more on this soon). This hackathon’s theme is cities, but other hackathons may be more open or have a different theme. Either way, I suggest trying a hackathon that aligns to something you are passionate about.  

Engaging Problem

For these past two hackathons, I was excited to be taking on a problem that was challenging and exciting to me – zoning codes. Zoning is something you may not think about but impacts the way many cities in the US are currently laid out. For example, zoning laws usually prevent a strip club from being built or operating next to a middle school (crude example but I think it makes the example very clear). In general, zoning regulates a city and town’s land use by permitting or prohibiting certain uses based on the zoning codes.

One problem is that most zoning ordinances are not easily accessible. Zoning laws and ordinances can be hundreds of PDF pages long and each zone can be extremely hard and sometimes costly to understand. This is Detroit’s Zoning ordinance – it’s a light read 😜.

Our idea, spearheaded by a guy who was passionate about this topic, is to help make this information easier to access and digest. Our idea is to create basic website that helps take this information out of the PDF and puts it into a more user-friendly web format.

Great People

The last major reason hackathons are awesome is because of the people you meet. Each event I met new and passionate individuals. Some of them are working on this zoning project, others have their own interests and projects. I met a data scientist who works at Ford but is from the Middle East where he used to be banker. I met an MIT graduate who engineered autonomous vehicles for a company that was purchased by Ford. I met a transit advocate who does design work for the Regional Chamber. Lastly, Jimmy, the guy spearheading this idea, works for the city of Detroit. He is a huge city, transit and do the right thing advocate. Also, he is a talented web engineer. It is always great to be surrounded by people that want to do great things and in an area that you are passionate in.

Try One and Check Out Our Project!

These are three reasons I believe hackathons are awesome. I participated in several of them over the years and I love focusing on learning, working on things I am passionate about and meeting great people along the way. I strongly recommend you try a hackathon to see what it is like. If you have similar or different thoughts, let me know! I’d love to hear what you think.

PS – Jimmy made some great updates yesterday and this project is already leaps and bounds exceeding my expectations. Check it out here: Zoning Guide Detroit

Group getting ready for the Inaugural Detroit Civic Hackathon in September 2019

Agile, Agile, Communication, Experience, Experiment, Failing, Focus, Improvement, IT, Leadership, Learning Lessons, Real Estate, Release Train Engineer, SAFe, Scrum, SDLC, Technology, Trying

A New RTE’s Struggles

As a new Release Train Engineer and former Scrum Master, I am ambitious and excited to dive in to help my train and teams succeed. In both roles, I struggle challenging and supporting my trains and teams to follow a few concepts, I believe are valuable.

Vertical Delivery (working software is the primary measure of progress)

Why is this important?

Working software demonstrates progress, enables healthy feedback into the development process without too much re-work and illustrates how much work it takes to deliver amazing software (plus we can celebrate the progress!)

My Struggle

Overall, shifting mindsets is hard. Our tech team can do the work. Moving away from getting everything together from the onset, is the difficult piece. Getting one piece of data from the database to the UI or even faking the data and getting data to flow from one place to the front end can be a big change. One thing I’ve seen that seems to help think through how to deliver vertically – during PI Planning, one team planned out what they would demo at the end of each iteration. If the demo description didn’t seem to deliver new value, the work may not be very vertical.

Set Based Design (assuming variability; preserve options)

Why is this important?

Change is inevitable. This helps designs and solutions pivot away from dead ends when new information is acquired. Also, this helps support innovation and conquer unknowns.

My struggle

From my perspective, during PI Planning or Iteration Planning the team has a clear idea of how they are going to do something and then go and do that thing. While this makes sense (SAFe also mentions how this is normal), it seems like we hurt our ability to innovate and try new solutions that may work better than just sticking to the plan (responding to change > following a plan). I don’t know if this is just a concern because of the technology we use and mindset we’ve created or if every organization has this kind of dilemma when also trying to deliver valuable working software.

Improved Predictability (program execution)

Why is this important?

Predictability helps others understand when they can receive their valuable working software. The more predictable a team, the better experience and experiences matter a lot. For example, if we expect websites to load within milliseconds and it takes 20 seconds to load a website that will result in a bad experience. That experience matters because we won’t go back to that website if it takes a long time to load.

My struggle

Sizing is hard. Sizing is an estimate, but it doesn’t need to be precise. I think this takes practice and the better the work is broken down, which also takes practice, the better we can size. I believe the skill of sizing can be improved and results in better expectations when it comes to major gaps. Often, I see rushed estimations (maybe because of pressure) or I don’t see a lot of time spent thinking through the estimates. Again, there is a delicate balance between wasting time on solving the entire story (analysis paralysis) versus getting just enough information to estimate how long it will take to complete the work.

What do you think?

I know the teams and trains I work with can execute on these concepts. I think as an RTE I can better support them in doing this by finding examples, finding mentors to help guide them and being unafraid to challenge “the why” when someone says it “can’t be done” like that.

I wanted to share my struggles because I think others have these struggles, and it is OK to openly talk about what we are working through. If anyone has any suggestions or thoughts, I’d love to hear from you and what you learned along the way!

Photo Credit: https://medium.com/@media_75624/release-train-engineer-rte-is-not-a-traditional-manager-b51536bd6664

7 Habits, Agile, Agile, Experiment, Focus, Goals, Improvement, IT, Leadership, Learning Lessons, PI Planning, Release Train Engineer, SAFe, Scrum, SDLC, success, Technology, Tools, Trying, Vision

Prioritizing for I & A and PI Planning

A few weeks ago I started a new position called Release Train Engineer(RTE). This role is responsible for facilitating the Agile Release Train (ART) moves efficiently and executes effectively.  

When I started the position in late June, I had 2.5 weeks to get prepared for the two most significant events within the Scaled Agile Framework (SAFe) that fall on the same week – Inspect & Adapt workshop (I&A) and Program Increment (PI) Planning. I & A is the final event during the PI and PI Planning is the kickoff to the next PI. I & A is an opportunity to celebrate all the great work done in the past PI and identify ways to relentlessly improve for the next PI. PI Planning kicks off the next quarter to determine what work can get accomplished within the PI.

I quickly realized with my end goal in mind (a successful I & A and PI Planning) I needed to identify what was the most important (and urgent in this case) things to get done and prioritize those items accordingly. (side note: in the future, I hope to find ways to move some of these items into quadrant 2, so they are less urgent and just as important)

Here is what I did to get ramped up and successfully facilitate I & A and PI Planning

  1. Identify the right people – Making sure I knew who the Product Manager (PM), Product Owners (PO), Scrum Masters (SM), Solution Architect and Software Architect were, was my number one item. This was my top priority because I needed to understand what work was going into the next PI Planning and understand how the current and almost completed PI was coming along. Asking questions to the right people would help me understand the most important information in a short period of time.
  2. Understanding the features being brought into PI Planning – This was my second highest priority because the RTE needs to make sure these items are ready for PI planning. The RTE doesn’t control this work and due to this, they should make sure features are as ready as they can be before PI Planning. If the features are not ready, the RTE needs to facilitate their readiness. In this case, we had a few features intended on being ready for PI planning, but one feature needed to be broken down. The PO and Architects did a great job of working in the last two weeks to get this feature broken down in a way that multiple teams could work together, rather than dumping all the work on one team.
  3. Making sure socialization happens and is helpful – Socialization is hard but important, which is why as a new RTE I wanted to make sure this was happening and going well. Socialization is a proactive preparation approach to PI Planning. If the features aren’t ready or unclear, socialization will suffer because the team will get bogged down by questions and may cause confusion in the future. A lack luster socialization will create inefficiencies in PI Planning, which can slow down a very fast paced two days (you can read my last article here about socialization).
  4. Brainstorming the I & A narrative – I & A is an opportunity to tell a story about the train’s journey during the PI. It is not a time just to dump data or point fingers. It is a time to improve and part of that improvement is to understand the context behind what happened in the PI using data to help elevate the narrative. I chose Grit as the anecdote to tell the story. The team has a ton of passion about Appraisals and persevered through many challenges. The data helped show how a lot of great things were achieved, despite the challenges throughout the PI.   
  5. Understanding data – Data can be dangerous if used incorrectly or misunderstood. As a new RTE who was not part of the train in the past, I was unsure what data was being looked at and measured throughout the PI. I talked with several of the right people (like the Scrum Master) to understand what they were or were not tracking. Also, I bounced ideas off other RTEs to identify what data made sense to use. I used a handful of data points in our I & A: Capacity Allocation – Planned versus Actual, Train Velocity – showing how work from another PI came in throughout the PI, and Cumulative Flow Diagram – showed how our cycle time was pretty good despite lots of unplanned work.
  6. Reviewing the SAFe site – When I started, I had a working knowledge of SAFe and the RTE role, but I am always learning and finding new information. In fact, I referred to the SAFe site on a regular basis when I was a Scrum Master. As I began to prepare my presentation, I constantly referred to SAFe’s site to make sure all my presentations hit on the major items needed for both events.
  7. PowerPoint – Creating my slide decks was really the last thing I did, BUT it took way more time than I anticipated. PowerPoint is not something I use often because I don’t give a ton of presentations and when I do use PowerPoint, I don’t make a bunch of slides. This time around, I knew I needed more information on the slides especially because of the Problem-Solving Workshop. Despite the time I spent working in PowerPoint, I still believe it made sense to prioritize this last because everything else I did before this gave me the content, I needed for my slide deck.

Image credit: https://www.developgoodhabits.com/eisenhower-matrix/

Agile, Communication, Estimation, Focus, Goals, Improvement, Leadership, Learning Lessons, Remote, Remote Leadership, Team Building, Tools

Great Teams > Improved Estimation

A few weeks ago, one of the teams I lead tried a different way to structure their two week build.

Instead of committing to work and tasking everything out at the start of the two weeks, we started each day committing & tasking work and ended each day seeing if we made those commitments. Also, we had a retro at the end each day to try and improve for the next day.

We tried this approach due to two identified issues (described in Day 0)

  1. New team members cause storming
    • We added two new team members and we were storming. Our old processes of accomplishing work changed because new team members needed to learn our solutions and that added time to what we thought we could accomplish in the past
  2. Estimating our work is hard and we were struggling with it
    • Due to adding more time to what we thought we could accomplish, we had trouble estimating what we could truly accomplish over a two week period (our build cycle). We found that we were crunched for time or dropping work as we neared code complete.

It’s been over two weeks since we started this process. What happened as a result of this different way of working? Did we improve our estimation due to this?

The short answer is no.

Instead, we accomplished something I believe may be more valuable. Our teamwork improved! Instead of improving our estimation, we improved our ability to accomplish whatever was put in-front of us.

Here is how our teamwork and ability to accomplish our work improved

  • Setting a daily goal made each day clearer
    • We had a really good idea of what we wanted to accomplish by the end of that day and it reduced questions because we could bring them up at the start or end of each day, if not earlier during our teamwork on Zoom (Day 3)
  • Increase in challenging each other created better solutions
    • We started to challenge each other more often, when something didn’t seem clear or there seemed to be a better way (Day 7)
  • Our daily schedules helped understand our real capacity
    • Simple yet effective because it helps us understand how much capacity we had to accomplish work that day (Day 4)
    • We established that we would always use Eastern Time when describing meeting times, so we don’t have to figure out all the different time zones (Day 6)
  • Leveraged Zoom more often to improve problem solving as a remote team
    • We started to improve our problem solving because we used Zoom more by talking about issues that came up and we began raising awareness to roadblocks earlier (Day 3)
    • Pair-programmed via Zoom more often for work that was newer to others, regardless of experience level – this helped everyone learn and improved teamwork (Day 1, Day 2, Day 3)
    • Brought people into our Zoom room, instead of having solo conversations, so everyone could hear the issue and bring solutions to the table (Day 8)
  • Thinking about what the work really required, rather than guessing/assuming
    • We started spending time each morning really thinking and solution the story via tasking to create as many tasks we needed to do to accomplish each story, rather than just creating a few tasks based generalities of what we were trying to accomplish
    • This also led to understanding potential roadblocks sooner, which the team then went and tried to solve immediately, rather than running into the roadblock during development (Day 4)
  • Building time for future work with time boxes to avoid getting in the weeds
    • If we thought we would bring in new work the next day, but we didn’t have familiarity with it, we would build time (30 minutes to an hour) to learn about that work instead of guessing on the time it would take to accomplish the work (Day 3)
  • Celebrate success often!
    • We did an excellent job of finding ways to improve, but we forgot to celebrate our success until later in the two week build. We did so much and it was amazing to see! (Day 7)

So what’s next for the team?

We continue to utilize these ideas in our day-to-day build process. We’ve even added to them. Most notably, we have a weekly goal and use daily goals that roll up to the weekly goal. These goals are based on business deliverables for a project we are currently working on.

Final thought

We set out to improve our estimation. Instead, we became a better team. That result is better than expected. Why? Great teams can accomplish any challenge that is placed in front of them, even if their estimation is off. Our team’s goal remains the same – create amazing software solutions to make the real estate experience faster and easier for everyone. Now the team is better positioned to accomplish that goal because we are one step closer to being a great team.

(Featured Image Credit: https://www.genequityco.com/insights/m-a-success-hire-a-team)
Agile, Estimation, Focus, Improvement, Leadership, Remote, SDLC, Technology, Tools

Daily Sprints – Day 4

Each morning for the next five days, I will post about the previous day and hope to provide some interesting insights on how the team is trying to improve their estimation! See Day 0, Day 1, Day 2 and Day 3 here!

What have you tried that works or doesn’t work?!

Day 4

The last day of the week brought some issues, but overall it was a very successful week.

The days two biggest issues

  • Sr. Engineer’s computer was back online but needed to sync all the code files and needed to install other software (so useless from a dev perspective)
  • We had a 1.5 hour vision meeting with our CEO
    • This isn’t an issue as much as it’s something that took away development time

Here is what we set out to accomplish for the day

  • Completely finish the story we started on Tuesday that we’ve been TDDing and pair-programming together (this is related to messaging functionality)
  • Solve the two issues that came up in Day 3
    • SPROC calls
    • Messages getting stuck
  • Configuration Story for an issue that happened on Day 1
  • UI issue from our last build that needed to be investigated and solved

Big Mid-Day Meeting

  • This was the largest meeting for the team. Overall, I think this meeting was worth the teams time, therefore, it’s ok that we don’t have a ton of development time this day.
  • Meetings can certainly cause issues due to the context switching and I think it’s critical for a team to understand how they can build time into their day to focus, while also building time to allow for some meetings.
  • A leader’s job is to help the team think about time management issues like too many meetings (which has happened on other teams in my past) so we can find ways to help the team focus.

So how did we do/what did we accomplish?

  • We finished the work, but didn’t check in the message functionality
    • WHY: it involves a paid service and we are being cautious about this story. On Monday we plan on talking more about a fail-safe for this solution
  • Two Day 3 issues (SPROC and Stuck in queue)
    • The engineer working on this solved both problems at the same time because our BA and engineer were helping each other think about the systematic process – without the BA challenging the engineer assumptions, they would’ve spent more time trying to solve the problem! Teamwork makes the dream work!
  • Finished the configuration story and our QA did the engineering! #crossfunctional
  • UI Fix
    • Still being worked on, but a new engineer took on this work and they are thinking about the solution in a different way, which is helping the other engineer who worked on this in the past think about new solutions for future needs!


Retro didn’t have a lot of items, mostly due to a shorter development day

  • Schedules – Similar to Day 2, the team looked at their schedules in the morning to take into account the time the meetings would take up
    • This is so simple, yet we forget about it so often. It’s great to see that a simple look at your calendar can help you understand what you really can take on throughout the day. If we forget to do this, we just assume we can take on work, which leads to over estimation without thinking about it.
  • Retro of Day 3‘s Retro – Thursday after retro, one engineer took ~30 min to look at the code to get a better idea of what they needed to task out and tackle at the start of this day
    • The engineer said that made a big difference in tasking out and understanding what the work would look like today (Day 4).
    • Moving forward, we will continue to build in time for our engineers to look at future work so they can be prepared and guess less.
      • This is another simple change that we’ve overlooked in the past and all it takes is 30 minutes or so of one person’s time.
(Featured Image Credit: https://menzing-mem.com/your-goals-our-solutions/develop-your-new-product-fast/)
Communication, Discipline, Focus, Leadership, Learning Lessons, Remote, Technology, Tools

Lights, Web Cam, Action!

At the start of October, I became a remote team leader and I am constantly in front of a web cam. Scary, I know (Happy Halloween :P).


Overall, remote life is not exactly what I thought it would be like. You don’t necessarily roll out of bed and start to work. That is what happened when I worked from home one day a week. Since this became my primary day-to-day lifestyle, I’ve noticed remote work is similar to the office except quieter and lacks structure.

Due to the quiet and lack of structure, remote work in my opinion, is more about discipline than it is about being comfortable working from your PJs. Comfort is important, but if you get too comfortable, you may not be discipline enough to accomplish your work.

When I set out to become a remote leader, I talked with a number of Quicken Loans FOC remote team members and leaders to learn from them. I wanted to learn about their experiences and how they worked through issues. Also, when I was working on The Mighty Docs team (#quackquack), I got excellent firsthand experience working with two remote team members.

Here are a few things I am learning and trying as a new remote team member, all of which require a level of discipline that I didn’t anticipate at first and seem similar to office work!

Leave your office after work

  • I heard it was important to develop a home office that is separate from where you “live.” I can’t financially do that, so I work most of the day at home and I go out at night. I don’t go out and party, but I’ll go to a park, ride my bike, workout, visits friends, grab dinner and take the time to really separate myself from my “office” aka my home.

Getting comfortable being on camera to be extra approachable

  • The Mighty Docs team set up a system where we brought the office to the virtual space. All remote team members (TMs) were on Zoom all the time and all Detroit TMs were on that Zoom when they were at their desk. Today, I’ve set up my own virtual office for anyone to come and talk to me whenever they need.

Over communicate

  • This is easier said than done. Technology makes communicating much easier, but it isn’t the same as face-to-face communication. To work through this, I try to check in with my TMs every day via any method I can, but at least a ping or text. I do this to see how my team members are doing because if I were in the office, I would come around to their desk every day or so to do the same.

Focus! – this works two ways

  • Increased Focus – with a quieter setting you can focus more on getting things done! This is what you typically read about with regards to work from home and improved productivity.
  • Lots of distractions – when you are on a conference call you need to stay focused on that meeting. It’s very tempting to look at another monitor and check your email while your team is having a discussion. Don’t do it!

See that wasn’t too scary…


Happy Halloween!!


Header Image credit – https://www.istockphoto.com/photos/pumpkin-headphones-halloween-squash?excludenudity=true&sort=mostpopular&mediatype=photography&phrase=pumpkin%20headphones%20halloween%20squash