A lot is being written about Scrum already. Scrum is dead and so on. Well when you have a vacancy for a “Manager” a “Janitor” or some other clearly non Scrum title but decide to call it a vacancy for a Product Owner or a Scrum Master. It’s you who are fucking up. just renaming the beast isn’t going to make it work like magic.

We’ve all heard it: “Let’s do Scrum, and Poof! We’ll deliver value in no time!” (Spoiler alert) it doesn’t work like that. Scrum isn’t some magic potion that turns chaos into order just by sprinkling a few ceremonies around. It takes a lot more than following the steps in the Scrum guide to get to real results. It’s all about teamwork, discipline, and having the right people in placeand believe it or not, it’s not that different from how things are trained in the army ;-).

Sprint equals Mission

Let’s start once again with the elephant in the room, the word “sprint.” We’re not actually running a race, are we? This term still suggests rushing to me, but in reality, we’re aiming for a deliberate, well-planned mission. Like in the army, it’s not about speed it’s about precision and success. A well-executed mission isn’t just thrown together, it is strategically planned and relies on everyone playing their role and pulling their weight to the finish line.

Doing a mission requires adaptation along the way. You are going to encounter unknown’s and you need to be prepared to deal with them instead of avoid/ignoring them and fuckup your mission.

Solving unknowns as a **TEAM**is what’s going to make an Agile/Scrum approach work.

Specialized, but all-round

In both Scrum teams and military units, we all have our own specialties and advantages. But here’s the kicker. We deliver value as a team. Just like the army, where soldiers are cross-trained to fill in gaps, we’re all-rounders too. If something goes wrong, we don’t just throw our hands up and call it a day. We adapt and get it done, together (as a team!).

Scrum doesn’t work without the right mindset {#scrum-doesn%E2%80%99t-work-without-the-right-mindset}

Scrum doesn’t run itself. Just adopting Scrum won’t suddenly create value. I’ve seen it happen. People think if they run the ceremonies and just follow some Scrum related steps, magic will happen. But without your team managing the process itself, it’s like trying to run an army mission with no captain, no briefing, and everyone just winging it. Sure, you might finish, but what have you actually done?

The army knows this well. There’s a structure, leaders who guide, but also a reliance on every team member being proactive. In Scrum, you need the right mix: a Product Owner with a mandate and an actual vision that backs the company, a Scrum Master who keeps the flow going, and a team that’s not just doing tasks but thinking about the bigger picture. You will achieve this mindset only by working together and keep talking as a single team.

A team that talks about the hard stuff

As a team we need to work together, talk openly, and tackle the hard stuff. I’m not talking about easy conversations where everyone agrees. I mean difficult, uncomfortable discussions about what’s not working or clear, what needs to improve, and how to get there. Only then right kind of delivered value is going to surface.

Discuss unknowns during your mission and get rid of them. Upholding a “daily scrum” wont magically teach that by itself.

How do you think Apple created the iPhone? Jobs and Ive didn’t sit around patting each other on the back. They argued, they iterated, they pushed each other until the product was right. And that’s how Scrum teams should operate. You don’t just do what’s easy or what’s fast. You work through the problems, challenge each other, and iterate until you’ve nailed it. You also ask a lot of (WHY) questions so you understand where each person is coming from.

Briefings and debriefings are crucial, but only if you commit to them

In Scrum, we have our Planning (briefing) and our Review and Retrospective (debriefing). Sound familiar? You can’t just jump into the mission without a game plan, and you sure as hell can’t improve without looking back at what went wrong or right. But, and here’s the caveat you have to actually use these sessions for what they’re intended. Too often, they’re rushed or treated as checkboxes. In the army, a failed briefing or debrief could cost lives, in Scrum, it’ll cost you the ability to iterate and test on things for the better the next mission. Take them seriously, or they’re just empty meetings not delivering any value.

Teamwork is everything

At the end of the day, both Scrum and military missions succeed because of teamwork. You need people who are committed, who communicate, and who have each other’s backs. Without that, you’re just a bunch of people shouting the are doing Scrum, and that doesn’t deliver any value at all. Scrum’s not about heroes, it’s about the collective goal. You win together, you lose together.

Scrum isn’t a holy hammer that solves everything.

So, here’s the thing. Scrum is a framework. It’s a humanly created structure designed to help teams work together efficiently. But just doing Scrum isn’t going to magically produce value for your company. You need the right people, the right mindset, and a clear mission that everyone’s working towards. Otherwise, you’re just doing tasks without any thought behind it—and that’s a recipe for failure.

Another thing: adapt your style of working to the needs of your business. there is a structure set by scrum you can adapt to. But dont be afraid to change some things if it works for the better for your company. The goal is creating a team that likes to work in the created structure and is able to deliver value instead of features.

You as a team or even a Company need to make it work by putting the right people (with a vision and mandate) and processes in place, or you’re setting yourself up for a crash landing not delivering anything then frustration.

Dont let solo managers trying to make themself look good take over your thrive for value and actually helping the business. Not hurting the business.

This post is a follow up on GIT deployment strategies within Kubernetes environments. Make sure you read this post first:

CI/CD pipeline with Docker and Git branching strategyExplore advanced CI/CD with Docker & Git. Master deploying Docker artifacts via Git branching. Dive into strategies for DEV, STAGING, LIVE environments. Perfect your pipeline now! All Subjects MatterRemco Loup.

In a CI/CD pipeline centered around Docker artifacts with the focus on a singular branch, implementing an efficient hotfix strategy requires a small deviation to ensure rapid deployment of critical fixes. Let’s work out our approach to hotfixing in this Docker-centric environment, given the explained branching architecture in the above post.

Identifying the need for a Hotfix

Hotfixes are a critical part of maintaining the stability and reliability of any software in production. They are typically required under specific circumstances that demand immediate attention. Understanding when to implement a hotfix is key to managing your CI/CD pipeline effectively, especially when using Docker artifacts and streamlined branching strategies like focusing primarily on a Single branch. Here are our scenarios where a hotfix can be necessary:

1. Security Vulnerabilities: One of the most urgent triggers for a hotfix is the discovery of a security vulnerability within your application. Whether it’s an exposed data risk, a potential for unauthorized access, or any flaw that could be exploited maliciously, quick action is required to patch the vulnerability and protect your users and data.
2. Critical Bugs Impacting User Experience: If a significant bug slips through your testing processes and reaches production, it can severely impact the user experience. This could be anything from a broken core functionality that prevents users from using your application as intended to severe performance issues leading to timeouts or crashes. If the issue significantly affects your user base, a hotfix is warranted.
3. Compliance Issues: Certain applications may have legal or regulatory requirements. If a compliance issue is identified that could affect your legal standing or user privacy, addressing it swiftly through a hotfix becomes a priority to avoid penalties or breaches of trust.
4. Data Loss Risks: Scenarios where there’s a risk of data loss or corruption for users require immediate attention. Whether it’s a flaw in how data is saved, updated, or retrieved, a hotfix should be deployed to mitigate any potential loss or corruption of user data.
5. Payment or Transaction Failures: For applications dealing with payments or any form of transactions, issues that prevent users from completing transactions or that might lead to financial discrepancies are critical. Such problems not only affect user trust but can also have financial repercussions for both users and the service provider, necessitating a hotfix.

Deploying a Hotfix

When a critical issue is identified within the production environment, the immediate goal is to develop, test, and deploy a hotfix as quickly as possible. Given that our primary branch for development is MAIN and that we generate Docker artifacts for deployment, we need a process that allows for rapid intervention without disrupting the ongoing work.

1. Creating a Hotfix Branch: Instead of branching off from your Production branch (as LIVE is not represented anymore in the Git repository in this strategy), the hotfix branch is created from the commit currently deployed in production. This ensures that the Hotfix is based on the exact state of the version running on the production environment. The specific commit can be identified through tags or Docker image labels that correlate with the production deployment.
2. Developing and Testing the Hotfix: The critical fix is developed within this hotfix branch. The urgency of the situation necessitates a focused approach, targeting the problem with minimal changes to expedite the testing and deployment process. Despite the rush, adherence to the Definition of Done (DoD) is crucial to ensure the stability and reliability of the hotfix. This can mean a condensed version of the DoD, prioritizing critical tests and checks that ensure the fix will not introduce new issues.
3. Creating a Docker Artifact for the Hotfix: Once the hotfix meets the agreed DoD criteria, an automated process builds a Docker image from the hotfix branch. This Docker artifact is then tagged appropriately, indicating its purpose and urgency.
4. Deploying the Hotfix: The newly created Docker artifact is deployed directly into the production environment, bypassing the usual DEV to STAGING to PRODUCTION environment strategy. This deployment is only justified by the critical nature of the fix and the testing it has undergone.
5. Merging Back and Maintaining Consistency: After the hotfix is successfully running in production, it’s essential to merge the changes back into the MAIN branch and any other relevant branches or tags. Only this step ensures that the fix is incorporated into the ongoing development work and future releases, preventing regression!!

Ensuring Rapid Deployment and Minimizing Disruption

• Automated Processes: Automation plays a key role in this strategy, from the creation of the Docker artifact to its deployment. Automated tests, builds, and deployments ensure that the hotfix process is as fast and efficient as possible.
• Communication and Monitoring: Rapid deployment of hotfixes requires clear communication among team members and close monitoring of the production environment post-deployment to ensure the fix is effective and does not introduce new issues.
• Documentation and Review: Documenting the hotfix process and conducting post-mortem reviews help in refining the hotfix strategy, ensuring that the team can respond even more effectively to future issues.

Conclusion

In a CI/CD pipeline using Docker and primarily operating through Git Flow, hotfixing requires a streamlined approach that leverages automation and focuses on rapid, targeted fixes. By creating hotfix branches based on the production-deployed commit, developing and testing fixes according to an well defined DoD, and deploying Docker artifacts directly into production, teams can address critical issues swiftly while ensuring the ongoing stability and integrity of their application.

Let’s dive into managing a CI/CD pipeline using Docker with a focus on Git branching strategy that involves development (DEV), staging (STAGING), and production (LIVE) branches. Our goal is to clarify the role each branch plays in the process, particularly how Docker artifacts are created and managed within this framework.

Docker deployment using Git Flow with multiple branches

The core of our branching strategy involved three branches:

1. DEV: This is where all development work happens. Every new feature, bug fix, or enhancement starts in a feature branch, branched off from DEV. Once the work on a feature branch is complete, reviewed and meets the Definition of Done (DoD), it’s merged back into DEV.
2. STAGING: This branch mirrors a pre-production environment. It’s where integrated features from DEV get tested as a whole and accepted by stakeholders to ensure they work together seamlessly.
3. MASTER: The branch that reflects the current state of our live environment. Only thoroughly tested and stakeholder-approved changes from STAGING make it to Production.

Git Branching and Branching StrategyIn this post, we will go over why branching is required, the difference between development, staging… DEV CommunityPreetham

This was our variation of a Git Flow strategy, we used until now. When you start working with Artifacts this all changes back to a normal Git Flow structure. We still have environments running (Dev, Staging and Prod). The real difference is that code commits get done once instead of getting merged into a branch running on Staging or in Production.

Instead we now have one Branch we called it Main. This is where a runnable artifact gets created after a successful code merge using Docker images. Everything deployed into our Staging or Production environment is a specific version of an earlier created Artifact.

The biggest change is that STAGING and PROD aren’t branches anymore where you merge code into. They have instead became environments that run a specific version of a Docker image. This all has its own challenges, especially when you need to Hotfix. Hotfixing has it’s own post which you can read after this post. Lets break down all of this without introducing hotfixing step by step first. It is comprehensive enough already.

What is an Artifact?

A Docker artifact, often referred to interchangeably with a Docker image, is a lightweight, standalone, executable package that includes everything needed to run a piece of software, including the code, a runtime, libraries, environment variables, and config files. In simple terms, it’s like a snapshot of your application and its environment, bundled together, ready to be deployed and run anywhere Docker is installed, ensuring consistency across different environments.

The Importance of DoD When Merging code

A comprehensive and clear Definition of Done (DoD) plays a pivotal role in this new process, even more when merging changes into a single branch that triggers a Docker image which should be runnable and deployable:

• Quality Assurance: The DoD ensures that all changes, including new features, enhancements, and hotfixes merged back into MAIN, meet a consistent quality standard. This includes code quality checks, successful completion of automated tests, and adherence to security best practices.
• Preventing Regression: By applying the DoD to all merges into MAIN, the team can prevent regressions and ensure that new changes do not negatively affect existing functionality. This is crucial for maintaining the integrity and stability of the codebase.
• Streamlining Deployments: A clear and comprehensive DoD facilitates smoother deployments by ensuring that only fully vetted and ready-to-deploy changes are merged into MAIN. This reduces the risk of wasting resources on building Docker images that are bugged or broken, and therefore contributes to more efficient and reliable artifacts.

Creating and Managing Artifacts

The first thing for this proces to work is when a forked branch is merged back into MAIN, this triggers an automated process in our CI/CD pipeline. Here’s what happens:

1. Automated Testing: First, automated tests run to ensure the new changes meet our quality standards. This is crucial for maintaining a stable branch.
2. Docker Artifact Creation: Upon successful running al tests, a Docker image (our Artifact) is created from the MAIN branch. This is because the MAIN branch is the single branch that represents the latest state of every DONE development, This is where we generate our artifacts from that can become “shippable” products.
3. Why using MAIN for Docker Artifacts?: Creating artifacts at this stage allows us to catch any integration issue. Since every feature merged into MAIN is going to be considered ready for a release, generating an artifact here ensures that we always have a tested and potentially deployable version of our product at hand.

Transferring from Branches to Environments

In traditional Git workflows, branches like STAGING and PROD are used to represent different stages of the development process, from testing to production. However, in a Docker-centric CI/CD pipeline, the focus shifts from using these branches for code integration to using them as references for deployment environments.

Deploying to STAGING

• Creating Docker Artifacts: Once development is complete and merged into the MAIN branch, a Docker artifact is automatically created. This artifact is a snapshot of your application at that point in time, encapsulating all the changes that were merged.
• Deployment, Not Merging: The STAGING environment’s role is to test this Docker artifact in conditions that closely mimic the production environment. Instead of merging code from MAIN to a STAGING branch, you deploy the Docker artifact to a STAGING environment. This means the code itself isn’t moving between branches; rather, the compiled and containerized version of your application is being tested.
• Purpose of STAGING: The STAGING environment is essential for comprehensive testing, including performance and security assessments. It’s a final check to ensure everything works as expected in a production-like setting without directly affecting your actual users.

Going to Production

• Stakeholder Approval: Once your Docker artifact has been rigorously tested in STAGING and approved by stakeholders, it’s ready to move to production. This step is crucial for ensuring that all features, fixes, and updates meet the necessary standards and expectations.
• Deployment to Production: The transition from STAGING to PROD involves deploying the tested Docker artifact to your production environment. This deployment process ensures consistency, as the exact artifact tested in STAGING is what gets deployed to PROD, eliminating any discrepancies between tested and deployed code.

Key takeaways

• No More Branch Merging for Deployment: In this streamlined workflow, STAGING and PROD branches are no longer used for merging code. Instead, they reference specific deployment environments where Docker artifacts are deployed for testing and production.
• Focus on Artifacts: The emphasis is on creating, testing, and deploying Docker artifacts. These artifacts represent stable versions of your application ready for STAGING and, eventually, PROD deployment.
• Consistency and Reliability: By deploying the same Docker artifact from STAGING to PROD, you ensure that what has been tested is exactly what gets released, increasing the reliability and predictability of your deployments.

This approach simplifies the deployment process, reduces the risk of errors, and ensures that every release is thoroughly tested in an environment that mirrors production as closely as possible.

Are multiple Branches still needed?

Given this new workflow, the STAGING and PROD branches in Git branching serve no active purpose anymore and therefore they have became obsolete. They helped track which versions of the code have been deployed to each environment which we have solved by running a specific version of an Artifact.

Conclusion

Incorporating Docker into our Git branching strategy streamlines the development-to-deployment process by ensuring that every merge into MAIN triggers a Docker image with the potential to go to production. The key to this strategy is the creation of Docker artifacts early in the development cycle, allowing for continuous integration and delivery while maintaining high standards of quality and stability.

By understanding the changes to Git branches and the process of creating and deploying Docker artifacts, we can rely on the complexities of CI/CD with confidence, ensuring that all new features and fixes are delivered to users as efficiently and reliably as possible.

Hotfixing

We havent spoken about hotfixing yet. As i said this deserves its own Post. You can read all about Hotfixing and its caveats here.

Hotfixing with Docker Artifacts in a Single Branch StrategyMaster hotfixes in Kubernetes with Docker. Learn to rapidly deploy critical fixes in a CI/CD pipeline focusing on streamlined branching. Perfect for tackling urgent issues without disrupting flow. Dive in now. All Subjects MatterRemco Loup.

Introduction

I first learned about Scrum way before the 2020 manifesto update was in place. So when we went to a Scrum master training after this 2020 release we had a nice little discussion about the change that has had the most impact with me since this update to the Scrum guide.

The shift from creating one inspectable working artifact at the end of a sprint. Into releasing much more frequently within the sprint itself. This is a real good thing since we live in a CI/CD world and holding something back when its Done is not necessary.

The problem i have with this is that it shifted the focus from my knowledge about what a Sprint Review was. And this got me thinking.

Some more background

For our team, achieving the “Done” status means a feature is primed for deployment. This doesn’t imply hurried releases; substantial changes are deliberated upon, ensuring they align with user requirements and broader objectives. Each update is meticulously vetted, with our Product Owner playing a pivotal role, aligning the release with business imperatives.

If you have a decent CI/CD implementation your team can forget that this update is released the moment it is deployed in our staging area. When we decide to pull the update trigger and go live is up to the business. The team will need to know when something is fully released since we also keep an eye on the potential issues. But the Developers should not have a stake in the actual release. I understand this needs some more explanation. We save that post for the future.

We do keep the DONE unreleased and DONE released separated in our DONE lane.

Our mini Sprint Reviews

To draw a finer point, our feature releases often resemble a series of “mini Sprint Reviews”

There’s a comprehensive discussion about changes and potential impacts.

Deployment timings are strategized.

Detailed changelogs are curated.

Stakeholders are kept in the loop, their feedback actively sought post-release.

This thorough approach often means that by the time our Sprint Review rolls around, the major talking points have been addressed.

This takes away some topics from the sprint review. Especially when you have a decent CI/CD in place and you work by frequent releases.

When you discuss and go live with updates before the end of the sprint and you got the feedback on the released features. Why bother people again to provide feedback of discuss the release again? Scrum is a framework that facilitates talk. But we do need value in this meetings. And to us the sprint review on this topic has become quite useless.

What do we discuss?

One might wonder, with such an exhaustive pre-release evaluation, what remains for the Sprint Review? We’re refining our approach, but here’s our current structure

Assessing our adherence to the sprint goal.

Analyzing tasks that remain untouched in the sprint.

Delving into ongoing development items.

Adjusting the backlog to reflect any changes from the last sprint, ensuring upcoming sprints have clear priorities.

Proactively identifying new tasks or adjustments based on our recent learnings.

Engaging stakeholders for detailed feedback where necessary.

Working like this offers some distinct advantages for us. Stakeholders are in all departments of our company. A lot of them work hybrid or even 3/4 days in a hybrid combination. By doing frequent releases and planning accordingly we discuss the release when they are in the company which just works best for us. The ability to discuss things face to face is invaluable. It just works better and creates more understanding between each other.

While our reviews traditionally fall on Fridays. This is not an issue since we can just notify the stakeholder any day we are done. Discuss the update. And go live. We dont have to make a whole lot of fuzz about these things. We have short feedback loops! Planning dreadful meetings is for slow moving large companies where everybody thinks they are important and keeps stalling things in bureaucracy.

Most of our Sprint Reviews dont discuss anything related to what we deployed. We dont inspect the increment. The increment is already inspected and we move on quickly to the other topics as discussed above.

Conclusion

A few essential components drive this approach of ours.

A Product Owner with genuine decision-making authority, ensuring alignment with broader business goals.

You need a Scrum team which works tightly together in completing full stories or features. Getting them really DONE. You need FLOW in your team to be able to pull this off.

You need a decent CI/CD framework in which you can deploy automated and frequently. (We are working on that ourselves. We are automated but not enough just yet. We can take out a lot more manual labor.)

As Scrum continues to evolve, so do our practices, always keeping value and efficiency at the forefront.

Introduction

First of all I want to say this.

Opinions are like assholes. Everybody has one…

I wont go any further but there are a lot of spinoffs for this quote. Do read on with a little skepticism.

The word “Sprint”

I keep having some difficulties using the word Sprint for every 2 week cycle of our product every time i think of what the word means to me. These sprints never stop! The moment a Sprint ends a new sprint starts…

In real life you at least can catch your breath and do some sleeping before travelling towards a new Sprint. And no a retro isn’t good enough. (SCRUM police) A new sprint starts the moment a sprint ends! The retro is also done within a sprint. (/SCRUM police)

I am a native Dutch speaker so my interpretation of the word sprint might differ. But to me a sprint instills going as fast as you can to finish first. Of course you obey the rules that wont disqualify you from winning the sprint. But the word rush comes into mind every time I think of a Sprint. Finish it! no matter what. This meaning gives a feeling of haste which isn’t gonna deliver cleaner code or less technical debt.

After finishing a sprint in real life I know i’m not physically capable of starting another sprint immediatly. So if you want to get in a flow as a team you have to actually stop rushing and start the discussion by talking to eachother. Take the time to make clear everyone is on the same page and we all see the same goal.

After all, SCRUM is a talk facilitating framework isnt it?

The word “Sprint” also means individuality to me. Which is unwanted considering your are a SCRUM team trying to get in a groove or flow together.

Achieving FLOW with Scrum.In this post I share my current journey of implementing Scrum and Kanban principles with my team, this is mainly about emphasizing the importance of real collaborative work and instilling a product vision which helps us to achieve FLOW which translates to high value Scrum for us. All Subjects MatterRemco Loup.

Just goofing around, but calling it an relay race (estafette) can be a better name! This also instills handovers and teamwork to be done with each other. The result is the same for the whole team if you compare it to a real life relay race. But still the aspect haste or rush is present here.

You of course don’t have to change this name but discussing this topic with your team is a thing you can do! Discuss this matter together with your, DOD, Acceptance Criteria and Sprint goal. At least make sure everyone understands that you don’t want the rush aspect that comes with the term sprint. Better do it the best you can obeying all defined rules. Instead of cutting corners in some grey area where nobody sees you do it!

Change that name!

And if we need another name. We can maybe use Development Cycles? This way we can call it Cycles like Linear does. Or call it Flows. For our 2 week Flow I have this Flow goal in mind.

For a name change to work we have to all agree on using this name. Tools like Jira already define a lot of these names that aren’t changeable. We as the development team are in a lucky position where Jira is only used for our backlog and administration purposes. But our physical Scrum board is our single source of truth of what we are trying to accomplish.

Our sprints only get registered on a higher level in Jira. All daily tasks that flow out of sprint planning arent registered within our Jira.

A journey into visual ScrumIn this post, I will share the experiments we conducted during the last three sprints with our physical Scrum board. The focus was about creating a better understandable visual representation of our sprint progress. Sprints are two weeks increments for us at this moment. All Subjects MatterRemco Loup.

Do not change that name!

The word “Sprint” itself isn’t a problem to me actually. But the word does bring things to my mind I do not like in our Sprints.

We dont want individuality in our Sprints.

We dont want to cut corners in Sprints.

We dont want to finish first at the cost of other aspects in Sprints.

We need to keep a keen eye on refining our DOD and using the right kind of Acceptance Criteria for our issues to keep the quality high. And most important define a proper Sprint goal every sprint and make it physical. Another name for Sprints isn’t gonna change that. We as a team will need to make it happen to instill quality over speed.

Changing a word like “Sprint” wont mean anything if you dont foster an environment in which the words rush and haste aren’t words that describe the work ethics. A sprint is just about an x week development cycle everyone understands, it shouldn’t be at all related to haste and rush.

Introduction

I am already for a while intrigued by transforming a business into a DAO (Decentralized autonomous organisation). Thinking of my role as a Product Owner i thought of a way that can work very well when transforming a part of our business into a DAO. We can benefit from Scrum, Agile and leveraging a DAO altogether this way.

In my personal case below, a hybrid approach is preferable, where certain aspects of our business are managed by a DAO, while the rest remains under traditional management for now. My DAO would be used to manage our Front/Mid/Backoffice system called BOSS to make decisions of what to develop next, while the broader business continues to operate in a more conventional manner. This approach allows our business to benefit from the advantages of a DAO, while mitigating some of the risks and challenges.

Our goal is to develop this system into a SaaS product within the travel industry. And use a DAO for example to get our stakeholders involved. But you will read more about my idea if you carry on.

What is a DAO?

a DAO, or Decentralized Autonomous Organization, is a type of organization represented by rules encoded as a computer program (called a smart contract) that is transparent, controlled by the organization members, and not influenced by a central government.

A DAO’s financial transactions and rules are maintained on a blockchain, which is a type of distributed ledger. This makes it completely autonomous and independent from any external or centralized control.

Imagine it like a digital company, where all the rules and regulations are coded into a smart contract. For instance, let’s say there is a rule in a DAO that a certain proposal requires 60% of votes to pass. This rule is coded into the smart contract, and the blockchain will ensure that this rule is strictly followed, and can’t be manipulated or bypassed by anyone.

Members of a DAO can make decisions about the rules or direction of the organization by proposing and voting on proposals, each having a vote proportional to their stake or shares in the DAO. In this way, a DAO is a bit like a traditional company but managed in a fully democratic and decentralized way.

To sum it up, a DAO leverages blockchain technology to ensure that the organization is governed in a completely transparent, democratic and decentralized way, free from any central or external control.

Tokens

Creating a unique token for a Decentralized Autonomous Organization (DAO) can be beneficial, and is a common practice, whether it’s the “best” practice depends on the specific goals and context of the DAO. Here’s why DAOs often issue their own tokens:

1. Voting Rights: Tokens can be used to represent voting power within the DAO. The more tokens a member holds, the more influence they have over the DAO’s decisions.
2. Incentives: Tokens can be used to incentivize certain behaviors or contributions to the DAO. For example, tokens can be given as rewards for completing tasks that benefit the DAO, such as coding, designing, or managing projects.
3. Fundraising: Issuing tokens can be a method of raising funds. Potential participants can purchase tokens, effectively becoming investors in the DAO.
4. Community Building: Having a unique token can help to build a sense of community among members. It can foster a feeling of shared ownership and mutual investment in the DAO’s success.

However, there are also challenges and considerations to keep in mind:

1. Regulatory Issues: Depending on the jurisdiction, issuing a token might be considered as issuing a security, which can have regulatory implications and legal requirements.
2. Token Distribution: Deciding on how to initially distribute the tokens can be challenging and controversial. The distribution method needs to be fair and align with the DAO’s goals and values.
3. Token Value Fluctuation: If the token is traded on the open market, its value can fluctuate, which can lead to instability and potential manipulation.
4. Complexity: Issuing and managing a token adds complexity to running the DAO. Not every DAO might need its own token, especially if its operations are simple or if it can effectively use an existing token.

How to leverage a DAO as a Product Owner

Imagine running a Decentralized Autonomous Organization (DAO) where your customers or interested parties are able to invest directly in your product. They’re granted stakes or tokens, which gives them a voice in your development process which is run in a Scrum/Agile way.

Let’s say these potential customers want a specific function, X or Y, added to your product. They can cast votes for that function using their tokens, directly influencing the development priorities. This voting mechanism can draw potential customers closer to your brand and empower existing customers to shape the product they use regularly.

In effect, the features that top their wishlist become the focal point of your development strategy. The beauty of this approach lies in its transparency. By allowing your users to vote on potential additions to your product, you’re showing them why certain features are prioritized over others. It’s a democracy where voting requires knowing the “why” behind each decision, leading to a detailed understanding of product evolution.

This approach is a boon not only for Product Owners but also for your business at large. Instead of cloaking your development process in secrecy, you’re inviting your users to be part of it. This participative approach can foster faster trust-building among customers and potential users than traditional methods.

As a Product Owner, you’re still essential in filtering and interpreting customer wishes, converting them into comprehensible stories that both technical and non-technical folks can grasp.

When it comes time to select top priorities, your roadmap is already outlined by the democratic vote. This interaction allows you to engage and learn from your customer base quicker than relying on personas or other traditional tools to decide what comes next. Majority votes could define your sprint goals, guiding your focus for the next development cycle.

What better way to foster transparency and customer input using Agile/Scrum in this way? This process integrates the principles of adapt, inspect, and learn in a tightly-knit manner. With a DAO-like approach, your product evolution truly becomes a community-driven endeavor.

Caveats

There are also caveats of course.

1. Governance Challenges: Implementing a DAO’s governance model can be complex. Balancing the interests of all stakeholders in a fair and equitable manner is a significant challenge. It’s not always the case that the majority’s decision aligns with the best interest of the project or all the stakeholders.
2. Smart Contract Security: DAOs operate on the basis of smart contracts, which are immutable once deployed. If there’s a bug or vulnerability in the contract, it can lead to severe issues, including loss of funds. The infamous “The DAO” hack of 2016, where $50 million was siphoned due to a smart contract loophole, is an example.
3. Regulatory Uncertainty: DAOs exist in a legal gray area in many jurisdictions. How they’re classified and regulated by law is still uncertain in many parts of the world.
4. Token Distribution: How tokens are initially distributed can also be a complex issue. If not done properly, it can lead to centralization or imbalance of power in the DAO.
5. Low Participation Rates: DAOs rely on active participation from token holders. However, voter apathy can be a significant issue, leading to decisions being made by a small subset of stakeholders.
6. Short-Termism: There’s a risk that token holders who are only interested in short-term profit might vote for proposals that yield immediate gains but are detrimental in the long run.
7. Interface between DAO and the Real World: DAOs are digital, but their decisions often have implications in the real world, where enforcement can be more complex.

Each of these challenges is surmountable, but they do require careful thought and design to address effectively. As with any system, the benefits should always be weighed against the potential risks and drawbacks.

The role of a Product Owner

This is where a good Product Owner comes into play and lets people not vote on your whole backlog but on clearly selected items that are already enough refined and ready to be developed to a degree of uncertainty. You are still supposed to know the overall market so you can preselect the items to be worked on and let people vote on them.

You still have stakeholders to keep happy and develop functions the market wants the most. Only by using a DAO and keeping people engaged you can adapt and learn your market way better then in other ways.

Even though a DAO is fundamentally democratic, it needs someone with a comprehensive understanding of the product to guide its development. A PO can offer insight into the feasibility and impact of features, helping to steer decision-making and prioritization.

Smart Contracts

A smart contract is a computer protocol that facilitates, verifies, or enforces the negotiation or performance of a digital contract. Smart contracts run on the blockchain, making them transparent, traceable, and irreversible. They’re designed to automatically execute transactions or other specific actions when pre-set conditions are met.

Here are some key reasons why it’s important to carefully design and implement smart contracts:

1. Immutability: Once a smart contract is deployed on the blockchain, it cannot be altered or corrected. This immutability makes it crucial that a smart contract is thoroughly tested and reviewed before deployment to ensure that it operates as intended.
2. Security: Smart contracts are vulnerable to bugs and exploits if they aren’t correctly programmed. Given the value often transacted or managed through smart contracts, security is of the utmost importance. Exploits can lead to substantial losses, as seen in the infamous DAO hack in 2016 where around $50 million was lost due to a bug in the DAO’s smart contract.
3. Financial Implications: Smart contracts often manage, store, or facilitate the transfer of cryptocurrency, and errors or vulnerabilities in the contract could have significant financial repercussions.
4. Trust and Reliability: The trust in a smart contract, and by extension, the entire operation or system it supports, heavily relies on the contract functioning as expected. Issues could compromise the perceived reliability of the system and discourage participation or usage.
5. Complexity and Interoperability: Smart contracts often interact with other contracts or systems. It’s important to think through these interactions to prevent unexpected behavior. Misunderstanding or neglecting the complexities of such interactions can lead to detrimental consequences.
6. Regulatory Compliance: Depending on the jurisdiction and the specific use case, smart contracts need to be designed to comply with relevant laws and regulations, adding another layer of complexity to their design and implementation.

Therefore, the design, implementation, and review of smart contracts need to be taken very seriously and conducted with utmost diligence. In many cases, it’s advisable to have smart contracts audited by a specialized security firm before they are deployed.

A written sample of a Smart Contract

So you need a good working contract on beforehand. The Product Owner can be the manager of such a smart contract for example. He adds the issues to the system. and the stakeholders can vote on these issues using their tokens.

Each vote raises the importance of the issues to be developed. After which you pick the highest ranked issues to develop on while keeping an eye of what you can work in a single sprint ofcourse.

You can also use two types of tokens for example. Normal tokens for your customers using your product and social tokens for potential customers for example.

Validity of tokens is also something to consider since wishes can become obsolete after time.

This all can become quite complicated and i might post a full sample of a smart contract written in Solidity in a later blog using the conditions above.

Conclusion

This has become a somewhat longer article then usual but it needed a lot of explanation to be able to understand what it means to leverage your role as a PO inside a DAO.

I hope this has helped a bit to clarify and explain what a DAO is and how it can be used especially from a SCRUM/Agile Product Owner point of view where both can really thrive.

Francois Fort wrote a article about this on scrum.org Are DAOs the future of Agile Organisations.

You need stakeholders to buy in and what is better then to have engaged stakeholders with stakes in your product leveraging a DAO? You get detailed and immediate responses from the market when you have a engaged diversified group of people wanting your product to succeed because they then also succeed .

Introduction

Without a “good” SME (Subject Matters Expert) stance, Every product is a lesser product then it can be.

This is the bomb I am am dropping here to start with.

There are off course nuances to this statement. I will explain below why this fact is true in my opinion. When you are a SME you care for your product in my opinion. Why would you know so much about the product otherwise? And also have all this information available? I tend to forget things i dont care about…. So i must care about our product.

Finding the nuance within a SME

The struggle is that you need to teach yourself how to react when you are uncertain or wrong. Being stubborn because you are afraid to fail is the wrong take on this stance. You also need to give other people the chance to learn what you might already know. Maybe even some new insights come to the surface! Dictating an answer isn’t going to help in accepting your answer until they figure it out themselves. And even more importantly it wont make the team smarter if they dont figure things out themself. The whole team needs to benefit, not just you.

This requires tact and the right moment to step in to certain discussions. You dont want to lead such a discussion but steer it in a natural way to the right direction when it occurs. And do remember there is still always the possibility that you are indeed wrong!

A “good” Subject Matter Expert

Being a SME is bloody darn handy when you have the upper hand on the positives a Subject Matter Expert can bring. That’s why this is one the most interesting misunderstood stances of a Product Owner to me. You can be totally in the wrong (misunderstood) as a SME or totally in the right. In a positive way without bothering yourself with everything, every time, again. And that is where you need to find your nuance within your role as a Product Owner with a SME mindset. Also if you know the details of something, also explain the WHY to the team. Keep involving them instead of being Mr Smart-ass.

Limitations

It is all a matter of knowing your limitations and being honest about it. You know a lot but not everything and the world evolves so things might be different nowadays. For me this involves in keeping my mouth shut when i am not sure. And also sometimes i give my take on why we made a choice in the past but i encourage everyone to seek it out in the present day since the problem back then might not be a problem anymore. And you always learn from these things even though the outcome might be the same.

It is good practice if there is somebody to give context to the choices made in the past without steering into a certain direction. I think there is a lot of value in explanations this way.

An analogy

The product we developed as a team started as a child of me. The vision came from me. It took us 2 years before we gave labor. And after that 2 year labor we teamed up to raise our child in the best possible way. This gave a lot of headaches but also brought us so much in learning and adapting to each other. We all started to care for this child.

How can i not pretend to be a SME for such a product? I am the one who started the initial idea. I was there when we gave labor after a 2 year period of close development. I was there all the way through its childhood watching it grow up and get mature. And even though it might be mature now our child still needs guidance and help from time to time. It is still my child after all. That more and more people also started to really care for this child changes nothing to the feeling i have towards our product.

Spread the love for your product across your team. Dont keep it to yourself. Make it better as a team.

Conclusion

I cant help it that i still remember almost every choice we made for our product in the past. And also why we made this choice within our development cycles. I dont particular choose to be that wise guy but this is a topic of interest for me and therefore i remember. I do need to give other people room for their own thoughts tho. So yeah i can relate to, and totally find myself within a Subject Matter Expert to a certain extend.

You do need to know/feel WHEN to step into a discussion. Dont get in a discussion being the wise guy all the time. This all might sound cocky or arrogant. But we all want the same and that is delivering a better product then it already was. If we keep talking in a respectful way without acting as the wise guy we are on the right track as a team.

And again! keep explaining the WHY’s and speak your mind. involve your team in decisions and explanations of choices made in the past. You are a team together with all people not just as the PO/SME.

Disclaimer: despite highlighting one stance of the Scrum master stances here. It is a combination of all stances that make you a better Product Owner. This is just one stance that interests me for being a misunderstood stance (and for a good reason). Without a clear Vision and “being” all the other stances you are going to have a hard time as a Product Owner.

Introduction

In this post, I will share the experiments we conducted during the last three sprints with our physical Scrum board. The focus was about creating a better understandable visual representation of our sprint progress. Sprints are two weeks increments for us at this moment.

Our Scrum board right now.

The image I will post below displays the board we have been using for almost a year. As we began to take Scrum more seriously we started to notice a lack of transparency with this board.

In this board we already resolved many of the problems we had previously encountered. These improvements are explained in detail in a previous post: Our sprints in real life.

To gain a better understanding of our journey, “Achieving FLOW with Scrum” is also a must-read. It delves into our background and, more importantly, answers the question: Why are we doing this?

These are the lanes and setup we use at this moment. We have split up the last two (Testing and Done) to improve transparency within our current CI/CD setup. Below is a list of things we have already tested and therefore are implemented on this board. On these improvements we will continue to incorporate when experimenting with new versions of our board.

The sprint goal is clearly visible.

We use green colored cards for the items contributing to achieving the sprint goal.

We mark tasks that are in testing to long with a visual exclamation mark.

We use “released” and “not yet released” in our Done lane to keep things that are DOD but not yet deployed visible for the Scrum team.

Our work order is put on the board in the Todo lane from top to bottom. Top items get worked on first unless there appears a good reason not to work in that order :)

Other tasks we committed to for the sprint are marked blue.

Random bugfixes and potential hotfixes uncovered during a sprint are marked red. They are put in the bottom of the board. They may be important but they came up during a sprint and are visible in the bottom of the “TODO” lane therefore.

Subtasks are always defined on this board. They are for the developers to do the work to deliver the full story. They may reside in Jira but the physical board is leading.

We use name cards to show who is working on what.

The reason we started experimenting with different board setups you will find below is that we increasingly started breaking stories down into subtask. However, when our developers completed a subtask. We didn’t want to remove it from the board immediately for a whole lof ot different reasons.

Removing a subtask creates less transparency and instilled less talks about done subtasks.

It gives developers that were out of the office (free) insight in tasks done when they come into the office the next day.

The most important topic was the lack of transparency this board still had on subtasks!

It also feels more satisfying to move a completed subtask to a designated area on the board. Slap it there, and move on. This provides a sense of closure. A feeling you wont get when you immediately remove, clean, and wipe out what you just accomplished.

In the first version of our board we didn’t account for this. Sometimes subtasks would move with the story. While other times a subtask moved to the “Done” lane. This is wrong! there isn’t anything to release or not yet released. It is a completed subtask of a branch probably not even committed yet. This situation created a lot of issues with regards to transparency.

First iteration changes

We started to experiment with splitting up the “Dev” lane with a “Doing” and “Done”. This way we could keep the completed subtasks in a designated lane. Although we noticed some initial irritation in starting with this setup. It was essential to try it out though to determine its effectiveness!

First iteration conclusion

After using this setup for two weeks, our final conclusion is that it’s helpful to have a designated area for placing “Done” subtasks. However, including this area within the current lanes of the board is not ideal. Completed subtasks should no longer be visible like this, they now appear as if they still need to move further to the right.

Subtasks themselves don’t move in Testing for example, as they are part of a story that holds the value. It is the story that progresses into Review, Testing, and Done. Thus, this approach is not recommended in our opinion.

We did agree to remove the cards when the developers as a collective felt it was time to remove them. But this method also doesn’t provide transparency either since there is no clear rule in place.

Second iteration changes

Together we came up with another version of the board. This version is again visible in the image below.

We reverted back to the lanes we had in the start of this experiment. Todo, Dev, Review, Testing and Done. We removed the visual representation of Todo and placed the Sprint goal there instead. We all agreed this was a more suitable location for the Sprint Goal.

We also decided never to move any work above the items representing the achievement of our sprint goal. For instance, if we start working on a blue or red item. This item moves to “Dev” while staying on the same horizontal line where it was initially placed. So, from now on, we aim to keep items horizontally aligned as they move through the lanes. The only exception is the Done lane, which is divided into sections for released and unreleased work.

The “Burn Pile” is a name we came up with for all done subtasks. We wanted to avoid having two “Done” lanes. It just feels satisfying to place the subtasks you just finished in this designated area! This approach not only provides a sense of closure but also offers insight into everything completed as subtasks.

Second iteration conclusion

This is the first iteration of our “Burn Pile” version. We have already discussed some other considerations for trying out this version.

We might need to add a reference to the story for transparency reasons. Or group the same subtasks of a story together for example.

We will learn from this experience by simply putting it into practice. It’s essential not to overcomplicate things immediately when it might not be necessary. As seen in the screenshot, we have already placed some subtasks in the Burn Pile, and we all agree that it feels good to physically do so.

Conclusion

We have decided that this board version is what we will be moving forward with for now. The first iteration did not work well due to having too many lanes, too much space, two Done lanes, and subtasks remaining too visible for too long after completion.

So moving forward from now on we will be using this version. I will keep updating this post every time we find improvements within our work using this board.

Introduction

I struggled for a long time with the idea of starting a blog. Not just to have a blog but to be able to share my perspective on certain subjects with anyone who finds it useful. This is my first attempt to explain my way of thinking and working.

The idea to explain how we at 333travel are achieving FLOW triggered me while reading the book Applying Scrum with kanban. As I started reading, I realized that many of the ideas presented in this book were ones that we were already using. Reading about these ideas gave me the courage to write this from my own perspective.

I am writing this post halfway in the book. Where Katie is exploring positive FLOW with her team where she acts as a Scrum Master. When the book started talking about FLOW, something deep inside of me got triggered.

I got the chills reading this chapter because I just realized that we already implemented a lot of the ideas in the book. Not knowing what Scrum or Kanban was in my early days. Just by trying what felt like a natural and good way to work, back in 2017 using agile methods.

Outcomes

We have made a lot of progress since then. I can already say we are practicing a lot of the outcomes that the book uncovers.

We started working with Jira in 2017 using a modified version of swim lanes.

Having a board with swimming lanes that cover the topics of issues.

Scrapping some swimming lanes since maintenance needs to be controllable and there has to be a use for them.

During the years that followed and when we really wanted to professionalize our way of working the following subjects entered our workflow. These insights are in no particular order.

Writing a definition of done (DOD) for each of the swimming lane states.

Having the sprint goal represented on our physical whiteboard.

Using a physical whiteboard that is the single source of truth over Jira.

Having specific colors on the stories we pick up within a sprint, with a special color (green) for the stories that contribute the most to the sprint goal.

Using specific colors for other tasks, hotfixes, and such.

Blocked issues aren’t a state where they can reside. Blocked issues need to get unblocked as soon as possible or rolled back after confirming that we can’t work further.

Working from a feeling that we need to finish off every task/story that is swimming through the lanes as a collective to the far right before we decide to start new work (stories).

For an visual insight on our current Scrum board i refer you to the bookmark at the end of this post.

Get a FLOW going!

Why i got triggered kept me busy for a long time. Thinking about it now, I understand that they were the catalysts to get our flow going. What I saw in my team was that only when people started really working together. (As in working on the same stories and picking up their subtasks within it.) Only then we really opened the way for conversations about the stories we are working on.

But in order to be able to do that we had to create a certain way of working first, covering all of the items listed above to foster transparency and focus.

Scrum is a talk-facilitating framework. To get a flow going you need to collaborate. Working on the same stories with all developers towards the sprint goal. Ideally, you should finish something before moving on to something new.

Developers often try to avoid really working together, thinking it creates more work. They often prefer to split stories further so they can work solo on stories. Instead of working on subtasks within the same story. This small change in behavior takes some getting used to for developers. But when they start operating as a team, they can enter a state of positive flow in which everything works.

If you keep doing this solo Scrum within a sprint, you’ll lose many of the benefits Scrum can provide. You can of course say you are doing Scrum. But do you want to say you’re doing Scrum? Or do you want to get in an epic flow together and forever change the way you work! (who cares what the name is, right)?

It’s our standard behavior to start working on tasks we already know best within a sprint (it’s quicker to finish that way, right?). I also challenge my developers to work on things they haven’t worked on yet within our projects. We need to get better as a Scrum team. This won’t happen if we keep working in our own knowledge bubbles. Developers need to be challenged to work together towards the product goal. This will give each developer more autonomy and confidence.

Scrum isn’t about the speed of development. this is merely a benefit when you reach a certain state of flow with your team.

Instill a vision

Instilling a vision is also crucial for FLOW. Having a idea of why you are building this product is one of the most important things to start with. A product vision or goal and a clear sprint goal to start from are a must. You need to be able to communicate your goal. This way you know what we are working on and what we need to do next to achieve that goal.

Defining technical debt is heavily relying on your product vision/goal. This enables you to compare your current product state to where you want it to be. And what technical debt we need to solve to get there.

A product vision isn’t concrete, and it doesn’t have to be long. It will evolve over time as you discover more about what the product will do and what the market wants. But it all starts with a vision you’re working towards. There needs to be something to explain WHY.

Conclusion

I hope i shared some useful insights in how we were able to achieve FLOW in our Scrum team. We are merely scratching the surface in my opinion, and a lot more optimizing still has to be addressed in our team. But we are are for sure on the right track.

Especially since our whole Scrum team has the feeling that we are operating in a FLOW. This is a pretty darn good feeling to work in!

Our sprints in a real life exampleThis post explains how we as a team manage our current Board on which we keep our sprints. This board is leading over Jira we love working analog next to our digital work. All Subjects MatterRemco

Below, you will find an example of our current visual whiteboard we use. (what’s a usable term?). I know that there are still a lot of issues to address to improve our board even further. We already accepted a long time ago that reaching perfection instantly is not possible. Try, Inspect and Adapt..

Mastering neater writing on a whiteboard is a skill everyone wants to own but requires a lot of time and effort. Not everyone is willing or able to commit to this ;)

Introduction

I use the words story below to break up something with subtasks. This is mostly a story for us, which also tells us we are open for discussing the how and the what.

A task is something that just needs to be done or is a specific request to run some query to get an export for example. not a lot of creativity in that :). A task is more defined in the what/how mostly. This is the main difference for us between the two.

Bugs and hotfixes are almost the same for us. except a hotfix gets fixed and deployed immediately. And a bug just moves as normal through the system. We both mark them red on the board so that is still something to work on for us also to create a visual difference.

Subtasks are tasks that get broken up from a story and needs to get done to move the story on. To keep it simple you can say we use the term story for tasks that can get broken up. I dont care about subtasks on the board from the DoD perspective. The value to me is in the whole story we committed to. Subtasks are removed after being done at this moment.

We are reviewing other versions to keep subtasks on the board for X time. I will write another post about these findings when we can analyze them.

Working: TODO & IN DEV

All subtasks under a story move in the TODO lane only when work on that specific story begins. This visually indicates a commitment to finish it. Once all subtasks are complete, the story moves between the lanes. This is because the value of the story must move as a whole into the DONE lane to deliver value for us.

This approach ensures that the TODO lane remains clean. This also makes sure that the focus remains only on the subtasks within the story that gets worked on. You could also say that the lane to the left of TODO on the board represents the sprint backlog. And we only pull in new work after committing to the part we are going to develop next.

When we are going to work on a task we physically move it to in IN DEV. When the subtask is done we remove it from the board. We also put our name tag at the subtasks we are working on. We may work on more then one task at a time if we see that the work is overlapping to much for example.

In the image above, we are just finishing work on our third story. The developers chose this story over the second priority. This was because it delivered more value at that moment. This decision got made due to sickness of one of our senior developers and a short holiday break of our PO. The morning that this photo got taken, our PO provided us with more details about the second story. This allowed the Developers to break it down into workable items/tasks.

Blocked stories

If stories are in the testing lane on the board after completing a new sprint. And this story was not a part of the current sprint we mark it blocked. In this case, we marked the story with an exclamation mark. We still focus work on this story of course. We still strive to move it forward, but sometimes it takes more time to move a story to the right. We may have to call in the help of the PO to move it forward or discuss with the stakeholders about its value.

This blocking state can get caused by an external factor, such as the task/story not getting tested. It can also be a quality issue where bugs keep coming up. And we are not being able to deliver the required quality until this gets fixed.
Every blocking story gets valued again at sprint planning. So we can determine if it is still going to be a part of the new sprint planning.

We can only have blocking stories in test the way we work. That is the moment we thought we delivered the value. This value is then already present in our release cycle cause we found it to meet the DoD.

This is also the part we focus on the most at this moment. Getting more quality before we move something in test. We only need our infrastructure to work along with that. And that is another topic we are working on. We are going to work with Kubernetes and this will solve most of our problems with the release cycle.

Finishing: IN REV & IN TEST

After all the subtasks get done and the whole story gets tested local by the developers. Only then the third story may move to the IN REV(iew) lane.

It is then reviewed by two developers after which it can move to the IN TEST lane. only after a positive review of both ofcourse. One exception is also that it may move on after getting reviewed by one developer and being 24 hours later.

This works for us cause we are a team of 4 and not everyone is available always and we also need to get confident and move on.

We currently have two testing environments, 31test and 32cur.

As explained already we are working on switching to automated DevOps with Kubernetes. This will make the way we work to the testing lane a much more automated experience. Another benefit is that this is also going to deliver more quality.

Finally DONE!

The DONE lane is split up for reasons i will explain below. Completed increments that are not yet deployed live are on the board in the “DONE not yet released” lane. This part of the lanes is the only lane that does not get emptied by the end of every sprint.

These items in the “DONE not yet released” lane need to get released of course. But that doesn’t always happen immediately. For example: we need to communicate about the changes before releasing them. Another example is when the specific feature is set to go live on a specific date.

As Developers, we do need to keep monitoring when these updates go live of course. Bugs may arise so we need to know what is released and what isn’t.

This also keeps a healthy discussion going about development done but not yet released. Having this visible adds to the transparency of what we are doing.

The released section under DONE means of course the item is live and fully deployed. This part of the lane gets cleaned every sprint. The items done here are being versioned after every sprint to keep track of progress.

Subtasks and visibility

We are still struggling with subtasks that are done. We want to keep them for a while for transparency it feels better to move a subtasks first after finishing it. This feels better then immediately removing them from the board.

We are currently discussing different variants of our board. We might create a space under the lanes where all done subtasks will get placed. Until the Developers decide to remove them of course. They are in charge of the readability of the board.

We are testing three different versions of our whiteboard at this moment. I will come back to these findings later.

Something about Jira

We dont have a rule to add subtasks in Jira. As a matter of fact i rather not see them in Jira. I use that mostly as my backlog and versioning system. Subtasks dont add any value for me in Jira until they get split from a story and become a task themself.

We do track and plan the whole sprint in Jira. But that is on a global level. The work done is mostly visible on our whiteboard. Stories of course move in both places. The board and Jira need to be in sync on the stories to be able to do my versioning and such.

If a Developer wants to add a subtask or needs to have a discussion about it we of course add the subtask to Jira. This way we can manage the discussed outcomes and discuss about them later on. This mostly happens on the parent story of course. But it isn’t impossible to have a discussion you want to register at a subtask at some point. We dont encourage it but we also dont forbid it.

Conversation

If i want to know where we are in our sprint i really have to walk to this board where the Developers also work. One benefit of this is the conversation that starts between the Developers and me as a PO. The developers see that I am available and I of course carefully choose the moments to walk in.

You do need to look out for disturbing the Developers to much and trying to track work to often. There is a balance in when you walk up there disturbing the developers with your presence.

This talk is often about things they were already going to ask today. Because they see I am available to them it is even easier to approach me in that moment and verify that last thing.

You do need to keep in touch with your Developers as a PO during sprints. Preferably even on a daily basis depending on the stories within the sprint. You are not just there to start and end the sprint. That isn’t a collaboration.