Mark Jivko’s Post

Agree on the principles

Awesome piece by Mark. I hear more and more engineering teams moving away from daily’s and into bi-weekly’s or even weeklys. You should foster constant communication lines between everyone instead of waiting for “tomorrow” to talk. I think Mark does miss on backlog vs future point. Your backlog should capture the different ideas, requests, tech debt and etc - but prioritized on weekly basis with the customer insights you should be gaining constantly. The fact that you have one customer shouting louder than others - doesn’t mean it’s the feature that should be built. That’s where a good Product manager will come in handy and make the right prioritization decisions.

"Empowering Developers: Embracing Autonomy in Handling Unfinished Work" In Scrum, one of the empowering aspects is giving developers the autonomy to decide how to handle unfinished work. Let's dive into this concept and explore the significance it holds for our Agile endeavors. 💪🔧 In the Scrum framework, we adhere to the principle that work should never roll over into another sprint. However, this doesn't imply that every single work item must be completed before the sprint concludes. Instead, we entrust developers with the power to make decisions regarding unfinished work. When a sprint comes to a close, any remaining tasks are returned to the product backlog, ready to be reevaluated during the next sprint planning session. This practice allows developers to assess the current state of unfinished work and determine the most appropriate course of action. During the sprint review, the focus is on showcasing the completed work and assessing whether the sprint goal has been accomplished. By empowering developers to make decisions about unfinished work, we promote transparency and prevent a rigid checklist mentality from taking hold. It's important to recognize that unfinished work presents valuable learning opportunities. The completed work, upon inspection, aids in adapting our future plans and refining our approaches. As a result, rather than blindly rolling over unfinished work into the next sprint, developers are empowered to leverage their insights and decide on the best path forward. If developers find themselves consistently unable to deliver a complete increment or if work items are interdependent, hindering the achievement of the sprint goal, this becomes a pivotal moment for introspection. It is an opportunity to reassess and refine our work refinement practices, ensuring that developers have the freedom to make informed choices that enhance productivity and success. By granting developers the authority to make decisions about unfinished work, we foster a culture of ownership, autonomy, and self-organization within our Scrum team. It empowers individuals to take responsibility for their work, encouraging adaptability and driving continuous improvement. Let's celebrate the power we bestow upon developers to decide how to handle unfinished work, as it propels us forward on our Agile journey, fostering growth, collaboration, and remarkable outcomes. 🚀✨ #EmpoweringDevelopers #AutonomyInScrum #UnfinishedWork #ContinuousImprovement #AgileJourney #LinkedInLearning #scrum

I'm really curious how companies/teams/people that say "Scrum didn't work for us" do software delivery. I've never worked in a successful non-scrum environment. Scrum is a tool. It solves something, but it can't solve all your organizational issues. It provides a framework for tackling: - Q&A sessions about features to be implemented [refinement session] - progress updates [daily standup] - demoing features to stakeholders [sprint review] - planning the timeline of the next batch of features [sprint planning] - continues improvements of the process [sprint retrospective] Development teams often complain that it just takes too much time and there are too many meetings, so they give up on scrum. But then they realize that these meetings will take place with or without scrum. However, with scrum, these meetings are structured, scheduled, and predictable. Without scrum, these are often ad-hoc meetings scattered during the day and week. You have to demo a feature to multiple high level stake holders? Can you imagine how much energy it takes just to find the time slot that suits everyone and to prepare (and wait) for that demo. And then you have to do this every couple of days/weeks. Same goes for refinements and all other sessions. I'm not saying Scrum is perfect, but just abandoning it without any plan or alternative ("we'll just tackle issues as they arrive") usually ends up with huge inefficiencies, time loss and context switching for engineers. That being said, I'd really love to learn about successful non-scrum teams, especially in corporate environments. #scrum #softwaredevelopment #meetings #pain_and_suffering

Calling All Tetris Fans 🟥 🟦 🟩 💥 Isn’t it satisfying when all the blocks line up? The faster things move, the harder it gets, but when blocks of different size and shape come together and those rows disappear… that micro-moment of achievement…. 🙌 Well, it can’t just be us, right? Helping you keep your program of work in order is what keeps us up at night, which is why we’re excited to share that Easy Agile Programs now supports custom sprint lengths. Need a shorter sprint at the end of this quarter to account for a company-wide event? We’ve just made it easy to help all the pieces fit together. This jam-packed release also includes confidence voting on the Program and Team boards, and delivers more visibility for risks and dependencies, including the ability to flag an issue that may cause an impediment to all those moving parts lining up neatly and delivering on time. Read all about it: https://hubs.la/Q02g_tby0 Easy Agile Programs for Jira is available now via Atlassian Marketplace. #agile #piplanning #program #SAFe #increment #confidence #sprint #tetris #scrummaster #agilereleasetrain #rte #bigroom

“We can’t use Scrum; we don’t have cross-functional teams.” (Bad parody of Princess Bride) “You keep using that word. I don’t think it means what you think it means.” A Cross-Functional Team does not mean it is all Full-Stack Developers. The technical definition of a Full-Stack Developer is someone who can do both the front and back end of a Website. More commonly, it defines someone who has multiple skills related to development. See also T-shaped and π-shaped developers. A Cross-Functional Scrum team quite simply means you have all the skills needed in the team to deliver an increment of usable value every Sprint. Do you need database skills regularly to deliver? - Have a DB person on the team Do you need a graphics layout person to deliver? - Have someone on the team that knows layout.  Do you need a marketing person to deliver? - Have that marketing person on the team. You do not need T-shaped, π-shaped, Full-stack developers for a Scrum team for it to work. You need the right skills so the team can deliver usable value every Sprint. Of course, having T-shaped people won’t hurt at all and can help. You don’t need that to do Scrum. This has been a 🦍 Gorilla Coach 🦍 Public Service Announcement. Have a nice day. #scrum #agile #effectiveness #continuousimprovement