Sprint 2 Retrospective

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

  • Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

  • Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

  • Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

  • Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

  • Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

  • Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

  • Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

  • Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

  • Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

  • Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

  • Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

  • Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

  • Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

  • Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

  • Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

  • Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

  • Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

  • Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

  • Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

  • Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

  • Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

  • Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

  • Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

  • Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Testing Documentation

For this blog post I read an article about test documentation. We haven’t talked about this in class yet, so I was curious to learn about how documentation for testing differs from normal documentation. The blog post starts about stressing the importance of testing and how it helps keep consistency, structure, and record keeping. The author then lays out their five key elements of good testing standards to keep in mind when working on a project.

The first point is that documentation should define the boundaries and scope of the project by detailing what they tests are testing for and how far the functionality of the application can go. This also helps with efficiency because it can keep people on the important objectives and not get lost working on things that are not needed. The next point is that documentation should reflect your testing strategy and approach. This includes mentioning what level or test you are running, unit, integration, or user testing (which is what my last blog talked about). It should also define the project specifications and the reasoning for the test and how why it is necessary to ensure functionality. A third element to have in testing documentation is to detail the software, hardware, equipment, and configurations for the testing, to reduce the number of variables that can account for unexpected and untested program behavior. Another key point is to have a test schedule and milestones as part of your outline and documentation to assist in workflow and keep large teams on track. The final part that should be included in the included information is the approach to be taken for defect management and error reporting. This will facilitate improvement by being consistent with company standards and working towards a complete set of tests. The author summarizes his suggestions that all comments and documentation should be consistent, clear, and regularly updated.

I wanted to look into a blog post about documentation because I know that it is important, and I personally rely on in depth documentation when looking at a new project for the first time. In this or other classes, proper annotation in code isn’t taught because of everything else that needs to be covered so I thought it would be a good topic to research on my own. With certain testing tools, sometimes it can seem that documentation is more than what is needed due to detailed automated reports that come with testing but when tracing code or looking through tests that have failed for any number of reasons it can be invaluable to have comments that describe a method’s intended function. Going forward, with the next project I do that involves testing I will make an effort to write proper documentation that follows the five elements described in the blog.

Test Management 101: Creating Comprehensive Test Documentation

From the blog CS@Worcester – Computer Science Blog by dzona1 and used with permission of the author. All other rights reserved by the author.

What is Integration Testing?

Integration Testing is a key phase in the software testing lifecycle where individual software modules are combined and tested as a group. While unit testing verifies that each module works independently, integration testing checks how these modules interact with each other. In simple terms, Integration Testing is where you check if different modules in your application play nice together. Each module might work fine on its own (thanks to unit testing), but once you connect them, all sorts of bugs can pop up—data not flowing correctly, broken links, miscommunication between components, etc. That’s why this type of testing focuses on the interaction between modules. You’ll hear it called things like “I & T,” “String Testing,” or “Thread Testing.” All fancy names for the same thing—making sure things work together.

Why is Integration Testing Important?

Even if all modules pass unit testing, defects can arise when modules are combined. This can happen due to:

  • Differences in how developers code or interpret requirements
  • Changes in client requirements that weren’t unit tested
  • Faulty interfaces with databases or external systems
  • Inadequate exception handling

Integration testing helps identify these issues early, ensuring seamless data flow and communication between components.

Types of Integration Testing

Types of Integration Testing

There are several strategies to conduct integration testing:

1. Big Bang Testing
All modules are integrated and tested simultaneously.

  • Pros: Simple for small systems.
  • Cons: Difficult to isolate defects, delays testing until all modules are ready.

2. Incremental Testing
Modules are integrated and tested step-by-step.

  • Bottom-Up: Test lower-level modules first, then move up.
  • Top-Down: Start with higher-level modules and use stubs to simulate lower ones.
  • Sandwich: A mix of both, testing top and bottom modules simultaneously.

Stubs and Drivers

These are dummy components used in integration testing:

Driver: Simulates a higher-level module that calls the module under test.

Stub: Simulates a lower-level module that is called by the module under test.

Final Thoughts

Integration Testing bridges the gap between unit testing and system testing. It ensures that individually functional modules work together as a complete system. Whether you’re using Big Bang or an incremental approach, thorough planning and detailed test cases are key to successful integration testing.

Reference:

https://www.guru99.com/integration-testing.html

From the blog The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

CS443: The Tribal Engineering Model (“the Spotify Model”)—An Autopsy

This codebase ain’t big enough for the two of us, pardner.

Something I think about quite frequently is how engineers seem to live in a world of their own creation.

No, really: open an app—look at a website—play a game of (virtual) cards. The designers of these programs each had their own take on how these experiences ought to be represented; the visual language, the information density, the flow from one experiential strand to another. These aren’t happenstance—they’re conscious decisions about how to approach a design.

But engineering is a bit like collectively building a diorama. Things look well enough in miniature, but the problems—with the product, and with the people working on it—become more clear the more you scale upwards.

This problem isn’t new, or all that far-fetched: engineers are specialists, and they’re good at what they do. Put two engineers together, and you’ve got yourself a crowd. Put three, and you have a quorum. Put a whole team of engineers on the same problem, and now you have a new problem.

(If you’ve ever wondered what happens when an engineer fears of being obsolesced out of their job, it’s not hard to imagine. It rhymes with “reductoring.” Alternatively, imagine a small, innocent codebase exploding into a million pieces, and you get the idea.)

So, how do you get engineers to play nice?

Plenty of solutions have been suggested; most of them involve Agile in some form or another.

(I personally don’t believe in it. I like—and have used—many of its byproducts, such as Continuous Delivery and Continuous Integration, but I don’t find that the underlying methodology behind the model itself is as universally applicable as it would have you believe.)

About a decade ago, there was a lot of buzz over Spotify having finally, definitively, solved the problem of widescale Agile implementation. It was highly ambitious—virtually utopian in its claimed economies-of-scale, with reports of unprecedented efficiency/productivity gains. Almost too good to be true.

Just one problem: it didn’t actually work. Also, they never actually used it, according to the testimony of one of the senior product managers involved in implementing it. Despite a grand showing in 2012, Scaling Agile @ Spotify was pretty much DOA before it had even hit the ground.

In hindsight, it should have been fairly obvious that things over at Spotify weren’t as brilliantine-sheened as the glowing whitepaper they said contained the key to their company’s success may have suggested. Years of complaints about incomprehensible UX decisions seemingly passed unilaterally with little user (or developer) input; a platform that abruptly pivoted towards delivering podcast and, strangely enough, audiobook content with almost the same priority as music streaming, and a lukewarm reception to the arrival of social networking capabilities.

So, what went wrong?

Firstly: every single organizational unit under this model, with the exception of Guilds, were ordered as essentially fixed, permanent structures. If a Squad was assigned to work on UX, that was their sole responsibility, unless a member had other duties through a Guild (more on that later). Accordingly, each Squad had equal representation within a Tribe, regardless of how important or pressing their work was. Further, each Squad had its own manager, who existed in direct opposition to three other managers in the same Tribe, who all had diametrically opposing interests due to representing different product segments. If an overriding voice was required, Spotify sought to preempt such issues by including a fifth Übermanager in a Tribe, who did not actually have a day-to-day purpose other than mediating disputes between managers, presumably because such instances were or were expected to be extremely common. (It is unknown whether this fifth manager was included in a similarly structured college of Middle Managers).

Worse, yet, however, is it becomes painfully evident how little work could get done under such a model. Because Tribes were, by design, interdependent on each other due to cross-pollination of key devs through Guilds, a work blockage in a Tribe not only required the intervention of two or more Tribes, but required the key drivers of the entire Tribe to do so, preventing any of the involved Tribes from doing any meaningful work. This is on top of the presupposition that each Squad has had to have mastered Agile in small-groups for the idea of an Agile economy-of-scale to even make sense.

Probably most damning, though, is the impulse to just double down on your own work when confronted by a deluge of meetings, progress reports, post mortems, and pulse checks. Rather than focusing on the interconnectedness of the Team-Tribe-Guild structure and how to best contribute as but a small part of a greater whole, many Spotify engineers simply did what they are instinctually led to do and submitted product as if working in small-groups.

This essentially created a “push” rather than “pull” system where engineers would deliver the product they had believed higher-ups would expect them to deliver, rather than the actual direction that Spotify executives wanted to steer them in. When noticed by upper management, these facilitated “course corrections”. Sweeping, unilateral, and uniquely managerial.

And that was pretty much the end of Agile for Spotify.

Things look well enough in miniature, but the problems become more clear the more you scale upwards.

So, why even talk about this?

I’ve had plenty of good collaborative experiences with engineers in industry. I want to work with people—I have worked with people, and well. But I believe there’s a science to it, and as engineers, we simply do not focus enough on the human element of the equation. The Tribal model reminds me a lot of Mocks, and even the POGIL methods we’ve used in this course so far.

Mocks are a way to implement that at an individual, codebase level. POGIL teaches us to think for ourselves and expand our individual skills. I think what Spotify failed to recognize is that people do not instinctively know how to work together, especially tech-minded people like engineers. Interdependence isn’t something to be cultivated absentmindedly, as if we could ignore the effects of losing the one person who knows what piece of the pie to cut for a day, week, or more; rather, it’s something to be warded against.

The Guinness pie from O’Connor’s in Worcester, by the way, is life-changingly good.

Some food for thought.

Kevin N.

From the blog CS-443 – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.

Customer and Enterprise: Why is one valued over the other

Photo by Anna Nekrashevich on Pexels.com

Hello, Debug Ducker here and have you ever thought how low quality a software you use feels, despite being made by a well known company. This is how I feel when it comes to videos games.

It was a thought that came to me during class when a professor said, if a company release buggy untested software that may ruin the companies reputation. A student ask well what makes the game industry different then. For those in the know the game industry has been plagued with the problem or releasing products in a buggy or half-finished state, that they expect the consumer to buy.

You would think after years of doing such thing, game development companies would be careful about development. Many gamers have criticized this on going problem within the industry and some gaming companies are seen in a poor light, though such reputation never seems to completely ruined them, it does make them less trustworthy. So why are video games different in terms of software testing.

This question kept bothering me, and I brought this up with a friend who may know more. He states that it is because that the consumer is not the most important person to disappoint, that in the software testing field the one who you don’t want to give a poor product or low quality product would be a company or a business. As they aren’t the average customer and have a lot more money to spend.

This is where I did a bit more digging and found out a lot of interesting things when it comes to making a product for the average consumer and making one for a company.

There is a lot of money making a product for a company. The graph from Dells revenue throughout the years showcase how much money can be made in enterprise products

As you can see the commercial products, which are products businesses themselves purchase make most of dell revenue compared to the average consumer. In a way I can see them being prioritized when it comes to reputation, you don’t want to have bad relations with the ones bring in the money.

There is possibly a more logical than financial answer to the question. Consumers are the common people and there are a lot of them. They may have different reactions to the product but since they are so many, there will always be someone willing to buy a product despite the quality. Then comes the company who probably needs the product to do a services and would prefer it thoroughly tested before getting it.

With this I can understand a little of why it is so important to test products in software testing especially when it comes to businesses. We need them for their continued support and they bring in a lot of money.

Admin. “Dell Statistics 2024 by User and Revenue.” KMA Solutions, 22 Apr. 2024, http://www.kma.ie/dell-statistics-2024-by-user-and-revenue/.

From the blog CS@Worcester – Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.