Agile, Estimation, Improvement, Learning Lessons, Remote, SDLC, Technology, Tools

Daily Sprints – Day 7

Each morning for the next three 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, Day 3, Day 4, Day 5 and Day 6!

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

Day 7

Every day this build, the team continues to show progress in thinking about how can we do better, even when it’s unrelated to the process of getting work done! Day 7 highlighted great examples of challenging each other for a better ways to solve problems and a bunch of collaboration between the team to push past issues.

Our goals for the day

  • UI Changes
    • The past two days, one of our engineers tried multiple solutions to solve this issue with little luck. They were understandably getting frustrated
    • Before moving on to discuss other goals, we talked about the process the engineer was taking to test their results, and we found that the engineer was taking a long time to see results, so we dove into their local testing process
      • Other engineers challenged the process this engineer was going through! It was awesome to see and the other engineer took the ideas in stride (see results & “what did we accomplish” below)
      • Examples of challenges
        • Why do you need to run all the services when the solution you are working is only using one service?
        • Why do you need to stop the services when you make changes?
      • Result: The three software engineers would spend one hour after this meeting going over the issue and thinking about what could be done – rather than the one engineer continue to try other ideas on their own
  • Message story bug
    • After we had the message solution in our test environment, we discovered a bug that needed to be fixed
  • Config switches
    • We were waiting on our DBAs to run some scripts and then needed to test those results
  • UI Integration fix
    • Issue was investigated in Day 6, now we wanted to solve the problem

What did we accomplish?

  • Config switches – done
  • Message bug –  fixed but more testing to be added
  • UI integration
    • Still working on the issue. We identified that we were missing our credentials file and now we just need to identify the file location
  • UI Changes – FIXED!
    • This was a great example of team work
    • After our goal setting meeting and the challenges towards the engineer who was taking on the work, the three software engineers came together and started to work through the local testing process that one of our engineers had been using for the past couple of days. The engineers identified two things to try that ultimately led to this story being fixed
      • One engineer helped demonstrated the waste behind running all the services, when we only needed to run the one that mattered to the solution
      • Our Sr. engineer helped point out how we could use Internet Explorer to better test CSS changes
    • After trying these ideas out, our engineer was able to solve the issue!

Retro

  • Code reviews
    • One of our engineers added a task for code reviews. This sparked some ideas if we should add these tasks to all of our stories
    • Another idea was to add a “tag” to a task to identify if the story was waiting to be code reviewed
    • Another idea that came up was adding another column to our Kanban board for code reviews
    • We are going to see if we can add a column to the Kanban board and if we can’t, add tags.
  • Talking about what went well
    • This was a great point mentioned by our BA. We’ve been using retro to just focus on how can we do better, but haven’t been celebrating our wins for the day.
    • Moving forward we will celebrate what went well, as well as, identifying what we can improve
  • Quick Business User Feedback
    • Great example of a fast feedback loop & communication progression
    • Our engineer noticed multiple data points that were coming in from different dates. The Engineer and BA talked about if we could just show the one data point or needed to show all of them based on date
      • This started as an instant message conversation and moved to a phone call. They recognized that they could get an answer from our end user
      • They called the business user to help make the decision
      • Once the business user called in, they got a quick answer and were able to finish the solution based on the feedback from our business user

Only a few more days left in our two week build!

(Feature Image Credit: http://www.corporatecomplianceinsights.com/the-light-at-the-end-of-the-tunnel-or-cliff/)
Agile, Estimation, Improvement, Learning Lessons, Remote, SDLC, Technology, Tools

Daily Sprints – Day 6

Each morning for the next three 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, Day 3, Day 4 and Day 5 here!

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

Day 6

Day 6 started well with no major issues! Our Sr. Engineer got his computer ready for development. Everyone had ample time in their calendar to work on development tasks! Pretty great that everything was working. What I personally found interesting over the last couple of days was how often things unrelated to our solutions come up that can take down development time.

Our goals after starting the day

  • Finish writing integration tests for the messaging story
    • Found a merge conflict because a file was moved outside the unit test solution
  • UI story
    • Testing last night, hard drive space prevented her from running the services
      • Cleared about 10 gigs
      • Code review out today
  • Configuration switch for one of our services
    • This was challenged by one of the engineers on the value of this over some other work in our backlog – we did end up working on it when we looked at our remaining work.
      • Great challenge here!
  • Investigating an issue with a UI integration that is broken

What did we accomplish?

  • Integration test were checked in, but there were questions about the software solution being pushed to our test environment
    • This is happens sometimes because of the schedule of when we push work to our non-prod environments. Our teams don’t have the ability to push work whenever they want due to a number of things. It does cause issues at times and prevents us from getting a faster feedback look (this is being worked on by another team)
  • We solved the merge conflict
  • We met with an Architect to get a Git project set up and build out an analysis tool for one of new projects that we started earlier this week (the messaging story)
  • UI Story
    • This story is making progress, but we weren’t able to check in any work. This solution utilizes XSLT which is not something we are very familiar with, so there are a lot of unknowns
  • Config Switch
    • We did end up working on it but we are road blocked with a DBA tasks to see if it is working
    • This also goes back to earlier in the week about calling out roadblocks earlier so we can be better at planning other work while waiting on roadblocks
  • UI Integration investigation
    • We were able to reproduce the issue but we can’t identify the cause due to the layers of UI elements that isn’t allowing for the error to be logged correctly
    • Our engineers plan on trying to add logging or find the error logs in the coming days

Retro

  • Working in different time zones
    • This is a unique problem to an all remote team. The team has team members on East Coast, Central and West Coast time zones
    • Our BA and Engineer in central time, set a meeting for 2:30. The BA thought 2:30 EST and the engineer thought 2:30 CST
    • We decided on defaulting all times to Eastern time and leave the responsibility of “translating” that time for the team members in their respective time zones
  • Offline files continue to cause issues
    • One of our engineers couldn’t run their solution because their hard drive was full
    • The engineer identified that about 50 gigs worth of files sync every evening, and they need to delete those in order to save space
    • This is another unique challenge that our engineers face at times. The awareness around this issue was great because they helped explain what to look for and the manual work-around of deleting the files until
(Featured Image Credit: https://www.naylor.com/associationadviser/advertising-during-economic-recession/)
Agile, Estimation, Improvement, Leadership, Remote, Technology, Tools

Daily Sprints – Day 5

Each morning for the next four 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, Day 3  and Day 4 here!

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

Day 5

Monday brought a few development concerns. Our Sr. Engineer was still getting his computer up and running. Also, Monday is Tesseract day.

Tesseract is Amrock Technology’s “innovation time” – the idea made famous by Google’s 20% time. Tesseract time is Monday afternoons and allows tech team members to work on anything related to self-learning, building innovative solutions and generally finding time to improve your skills.

Why is this important to this post? It takes half a day away from our development time (in a good way).

After starting the day, we laid out our goals with Tesseract in mind

  • Check in the messaging functionality
    • Also need to add a column in the database
  • Build an on/off config switch for this message functionality
  • UI Fix for how information is displayed

After talking about our goals our team had a great discussion about our “internal code complete” which I touched on in Day 0. The BA asked if we were trying to hit Tuesday end of day internal team code complete. A few challenges and ideas came from the team

  • We talked about spending time testing for two days (how we used to do things)
    • Challenge to this – if we have tests in place (especially if using TDD), we shouldn’t need two days for testing
    • Realistically, we aren’t using TDD on some of this work due to the work it would take to get all the testing in place (mocks/fakes) for stories that are much older – we were using TDD on a new project at the start of this build, for our messaging story
  • The topic of fixing things came up and using two days to fix things
    • Challenge to this – if we are breaking things down into smaller chunks and checking work in earlier, we should shrink this “two days” down because we are getting faster feedback when we check in early and often
    • Also, if we are writing tests (unit and integration) as we go we should know how we are doing as the build goes on

My take away from this – IT’S REALLY HARD TO BREAK AWAY FROM OLD HABITS! Habits form and they make you comfortable, even if they don’t create the desired outcome like we tried in the past. Leaders should challenge our own habits and our team’s habits, when we believe there is a better way because we aren’t seeing successful outcomes. Also, leaders should empower their team members to challenge these habits, because they may have a different point of view of the issue.

How did we do with the shorter day? (note how little we aimed to achieve this day because we looked at our schedule and knew we only had a morning or so of development time)

  • Message story was checked in and pending reviews from our DBAs and engineers
  • On/Off switch for the messaging was checked in
  • UI fixes were worked on but not completed

Retro

  • Retro was pretty short due to the shorter development day
  • Remote computers seem to have space issue
    • Two engineers are having hard drive space issues, which is causing issues for them because they need to delete files before they really can move forward
    • They mentioned how even after they delete the files the space gets filled back up pretty quickly, which is interesting because maybe there is something specific to how remote computers sync with our network compared to how in-office computers work. Anyway, this is one of those fun problems that pops up from time to time but can be pretty disruptive

On to the next day 🙂

(Featured Image Credit: https://medium.com/@JimWexler/the-science-of-habit-breaking-e3fe6177599d)
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

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/)
Agile, Estimation, Improvement, Leadership, Learning Lessons, Remote, SDLC, Technology, Tools, Vision

Daily Sprints – Day 3

Each morning for the next six 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 and Day 2 here!

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

Note: each day I write this, I am trying out different ways to be more concise and impactful.

Day 3

Day 3 started a little better than the past few days. Our Sr. Engineer was still sick, so we were down one team member. Otherwise, nothing major came up before our day started.

Also, we actually used our first meeting of the day to go decide on a goal and identify what else we need to accomplish, rather than our older standup updates.

Our goal for the day :

  • Finished the unit tests that we didn’t complete from Day 2
  • Finish writing the contract logic
  • Identify solutions for issues that came up from our Day 2 issues that we need to start working on
    • Messages getting stuck in a queue
    • Spike in SPROC calls

How did we do and what did we accomplish?

  • Finished the unit tests for the contract
  • Set up the contract and added it to Git!
  • Local solution for the messages getting stuck in the queue
  • Identified a plan to solve the SPROC issue
  • Our BA discovered an issue with another solution causing a bad user experience
    • An update to how we display data coming from an integration is displaying the correct info, but not displaying all of the info like we expected
  • Talked with the an Architect again about his thoughts on a solution for the bigger project we got started on this build

What do we have to do next?

  • We ran into a small roadblock for finishing up the contract component, where an Architect needs to approve and make a change on his end to update the messaging service NuGet package

Retro

  • Identifying roadblocks sooner and listing those out in tasks for the story
    • When the team was working, they ran into a road block (described above). This was a known roadblock, but we never explicitly called it out or planned for it
    • Moving forward, we will try to identify these up front and task them out so we can think of ways we can still work on things in parallel, while the road block gets worked on.
  • Tasks can be broken down further
    • Similar to the road blocks, we noticed that we had some tasks on the board that we started working on but we didn’t quite finish
    • What we decided on doing was breaking those tasks down to what we accomplished and what was still remain
      • This may prove to be a great tool for us when we look back and think about what we actually accomplished and how long it took us to accomplish
  • Prepared to task, less guessing
    • We ran into an issue at the end of the day where our BA asked what we needed to do to accomplish one of the stories. Our engineers started to think, but it became clear we were guessing without much information.
    • We decide one of our engineers would take a look at the story after our retro and prepare ideas of tasks for the following morning so we could hit the ground running with less guessing
(Featured Image credit: https://www.chameleoni.com/three-common-team-building-options-to-avoid-because-theyre-just-sad/)
Agile, Estimation, Goals, Improvement, Leadership, Learning Lessons, Remote, SDLC, Technology

Daily Sprints – Day 2

Each morning for the next seven 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 and Day 1 here!

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

Day 2

Welcome to Day 2!

Does your day go exactly as you planned? Based on Day 0 and Day 1, we weren’t expecting things to go exactly to plan and we were right!

Unexpected issues to before 10am:

  • Our Sr. Software Engineer called out sick
  • The new solution that was broken and fixed on Day 1 gave us a few more issues
    • Our database team started wondering why the new solution was making hundreds of Stored Procedure calls per minute – we weren’t sure why, so we started to investigate
    • The new messaging platform we are using for this solution had a good amount of messages looking to be re-queued and we weren’t sure why

At 10am the team gathered for “standup,” which in Day 1 we decided we would re-purpose for a daily goal setting meeting to identify what we were going to accomplish. I forgot that and started in with my updates, which totally blew up the flow of what we wanted to do. Luckily the BA on our team called me out for it, so I won’t forget next time.

The team decided to try and achieve this goal for the day

  • Finish the story we started yesterday
    • Write remaining unit tests
    • Complete the business logic
    • Write contract logic for messaging

How did the team do? We didn’t complete everything, but we made a lot of progress.

  • Wrote most of the unit tests – there are still about 8 more to go
    • When the team started testing in the morning, they continued to run into a fakes issues from Day 1
    • They received assistance from a Sr. Engineer on another team that identified a DLL was missing and needed to be referenced in order for the fakes to work
  • After writing most of the tests, most of the business logic was completed
  • The BA diagrammed out the process flow for our tech solution to this project in preparation for an architecture meeting

What’s remaining with this story?

  • 8 more unit tests
  • Finish writing the contract logic for the messages

What did we take away from our end of day retro?

  • The engineers used the “give control feature” on Zoom to give allow others on the team drive, so we didn’t have to waste as much time switching computers
  • When the team broke for lunch, they talked about where they would pick back up and discussed their afternoon schedules so everyone could coordinate their pair-programming
    • Great example of self-organizing!
  • Shelve Sets caused some issues because one team member went into a meeting and another forgot to grab their shelve set
    • Decided at the end of each day we will shelve all of our work, so we can avoid issues when people are not working together
  • Change the name of our “stand up” meeting to a Daily Goal Setting/Tasking meeting and list out the items we should do before we start for the day (get latest, grab shelve sets, load solution )

See you tomorrow for Day 3!

(Feature image credit: https://goo.gl/images/ZsxQzt)
Agile, Estimation, Improvement, Leadership, Learning Lessons, Remote, Technology, Tools

Daily Sprints – Day 1

Each morning for the next eight 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 our previous day here!

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

Day 1

Day 1 started with tons of issues! We pushed a new solution to our prod environment on Tuesday morning and one of our applications was completely broken. A number of team members, including three from the team went into the technology ER and started troubleshooting from 7:30am till about 10:30am when we finally resolved the issue. Shortly before we solved that issue, our most experienced engineer texted me saying his computer was failing to start up. Turns out his motherboard died.

Before 10:30am, we had four out of six team members unavailable to do sprint work (three team members fighting fires and one team member without a computer)!

We started stand up after we finished solving the broken solution and our team member without a computer called in (we are all remote). We identified one of the three stories we wanted to start with and agreed on trying to complete these story tasks by the end of the day.

  • Set up our unit testing project
  • Decide where the business logic will live
  • Write a passing unit test against the story we are working on

The engineers came together in Zoom and started to pair-program the above goals. We had one of our engineers in California drive, while our other software and quality engineers navigated the code writing, telling the driver what to do and where to go. Additionally, it may have been a blessing in disguise that our Sr. Engineer didn’t have a functional computer, because it forced him to be a guide rather than a driver.

Before we finished the day, we met with two architects to help guide us on some questions that we came up with on Day 0 when talking about the design of our overall project.

At the end of the day, we came really close to accomplishing everything we set out to do, despite the crazy morning. We were unable to finish the unit test due to some issues with some of our fakes.

Lastly, before we broke for the day, we came together and talked about “what we accomplished” and how can we improve for the next day.

A few other takeaways from our end of day “retro”

  • Collaboration between the engineers was amazing – everyone was providing input and insight!
    • All the engineers worked together using Zoom
  • As a remote TM, our network lag is not ideal and it takes a significant amount of time to get solutions built, download updates and generally things are a little slower when you aren’t in the office.
    • Starting Wednesday, we made a decision to make sure everyone gets the latest solution and has their solution ready to work on before we start to work together, so we can reduce some of the down time it takes to get those things up and running
  • The “left out” effect is powerful
    • Our BA, who was working on getting things prepared for the next day and not collaborating in writing code, mentioned ‘wow sounds like you all had a lot of fun, seems like I missed out’
      • This is really interesting comment. I thought this was great, not because one of our team members feels left out, because behind that comment is a nugget of truth – collaborating together and taking on a challenge is fun, exciting and contagious!
  • Tackling one story, using a new way to attack the story (TDD), takes more time than anticipated
(Feature Image Credit: https://www.joc.com/trucking-logistics/labor/international-brotherhood-teamsters/teamsters-face-uphill-battle-drayage-segment_20140711.html)