The Product Backlog: Your Secret Recipe for Bringing Products to Life!

If you were a chef in a busy kitchen, then the pages in your favorite recipe binder could be your Product Backlog. You would not consider this binder to be merely a list of ingredients, right? But more like a prioritized collection of culinary wonders waiting to be cooked up into a delicious masterpiece! So, exactly as a recipe guides you step by step, the Product Backlog steers you towards creating a delightful product. It’s a collection of ideas, features and improvements, all carefully prioritized to make sure you’re working to create the most valuable experiences to your customers. A powerful thought to deep dive on: Is your Product Backlog coming up like a well curated menu, or is it more like a disorganized kitchen drawer stuffed with arbitrary ingredients? Prioritization is the secret dressing! In the same way as an expert chef would skillfully select the finest ingredients for a dish, you need to prioritize the Product Backlog Items (PBIs) that bring the most value to your customers, users and business. This is as kin to finding that perfect balance of flavor and value! Ready for the final gem? Roman Pichler, one of the Agile Product Management Gurus’ wise words echo loud and clear: “The Product Backlog is a prioritized list of work remaining that is necessary to bring the product to life.” To all the Scrum Masters, Product Owners and Agile enthusiasts, I urge you discover the true power of the Product Backlog by embracing the art of prioritization. Craft a delectable menu that delights your customers, and watch as your products come to life in the most amazing way! ✨ Adapted from Agilonomics’ LLC LinkedIn post (June 2023)

Risk: Barrier or Gateway to Opportunity?

Risk: Obstacle or Opportunity?

Do you view risks as just obstacles? Here’s why you should be seeing them as opportunities In product development, risks are often seen as just another obstacle to overcome. But what if you could turn each high-risk item in your project into a potential opportunity? That’s where the concept of “driving a bus through a wide-open window” comes in Each high-risk element is like a bus that needs to be driven through an open window of opportunity. The bigger the bus, the bigger the window needs to be   To make risks work for you, it’s crucial to tackle the biggest risks early on. During the earliest stages of development, the window of opportunity is wide open, making it easier to drive the big buses through    But as each day passes, the window closes a little more, and if you don’t find the big buses in your project early, you’ll end up with a disaster at the end, as the metaphorical bus crashes into the nearly closed window   That’s why it’s so important to focus on the highest-risk elements from the very beginning, building them early and validating them with each sprint By doing this, you can turn risks into opportunities and achieve potentially shippable software with each iteration So, what are the big buses in your project? How can you drive them through the window of opportunity before it’s too late? Remember: The earlier you address the biggest risks, the better the chance of succeeding with your best ideas As each sprint goes by, your window of opportunity becomes smaller and smaller By driving the big buses through early on, you can turn risks into opportunities and achieve success in your product development journey. (Taken from Amit’s Linkedin Post last April 21, 2023)

Agile Principle #2

Agile Principle on Change has been misunderstood for too long. Many orgs and teams view it as an excuse to make rash changes. But this couldn’t be further from the truth. In reality, effective change stewardship is critical to succeeding with Agile. Agile Principle #2 states: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” This doesn’t mean that changes should be made haphazardly or without involving the right stakeholders. An example of this Principle often being abused is: Product Owner, Engineering manager or an influential stakeholder repeatedly brining in scope creep into a Sprint after the Sprint starts, justifying by saying that team should welcome change. The correct way to do tackle such a change would be to bring it to the Product Backlog; reprioritizing the Backlog working with the team. Such an approach to violating and abusing Agile Principles leads to bad habits and anti-patterns. Remember, as Agile leaders, practitioners, and project managers, we have a responsibility to manage change effectively. This means embracing change as an opportunity, not a burden, and taking a thoughtful and strategic approach to change management. Effective change stewardship, therefore, requires clear communication, collaboration, and a willingness to adapt. It involves not just the project team, but also the stakeholders and customers who will be impacted by the change. As Agile practitioners, we must be willing to challenge ourselves and our teams to think differently about change management. We should ask ourselves: How can we involve stakeholders in the change process in a meaningful way? How can we communicate the impact of change effectively? What risks and benefits are associated with the changes we’re making? Do we understand the deeper meaning of the Agile Principles on change? The truth is, effective change management is not easy. It requires us to be proactive, to seek out feedback, and to constantly adapt to new challenges. But when we manage change effectively, we can deliver more value to our customers, improve our processes, and achieve our project goals. So, Agile practitioners, let’s embrace change as an opportunity for growth and improvement. Let’s challenge ourselves to think differently and to be proactive in managing change. And on a surprising note, the Agile Manifesto Principle on Change is not just about managing change during development. It also applies to our own personal growth as Agile professionals. As we continue to learn, grow, and adapt to new challenges, we are harnessing change for our own competitive advantage. (taken from Amit’s Linkedin post “February 27, 2023”)

Turning Setbacks Into Stepping Stones

The most successful people don’t take setbacks as “The End” but rather as an opportunity to propel them forward.  Thus, they develop this uncanny ability to turn setbacks into opportunities 🏆 They don’t go down to failures;  instead, they use them as springboards to trigger their path forward to success. 🏹 It’s easy to get discouraged or feel low (aka “feeling like the end is here?”)  when things don’t go according to plan, wishes or as desired But did you know that  the most successful people don’t have a magic formula for avoiding failure? They just have a different way of thinking. 💡 [siteorigin_widget class=”SiteOrigin_Widget_Video_Widget”][/siteorigin_widget] They see failure not as an end, but as an inseparable step towards the journey to success. 📈  They see every setback as an opportunity to learn, leap and grow and help them move a step or two closer to their goals. 🎯 So the next time you face a setback, remember “giving up” is not an option. Take a few deep breaths, assess the situation, and ask yourself: what am I learning here? How can I use this experience to become better, stronger, and even more resilient? 💪 Remember, success is never going to be a straight line. It will be a winding road with plenty of bumps and detours along the way, and that is what will make it fun, memorable and worthwhile. 😍 Go on, embrace the journey, and don’t be afraid to fail. Remember, the only way to guarantee failure is to never try at all. 💯 (PS: I wrote this with the hope to inspire several friends, networkers and all the people who have been impacted by the economic downturn and/or decisions that were not favorable to their plans) Learn More  

Agile Triangle: Balancing Constraints for Success with Agilonomics

Understanding the Triangle of Constraints

Is your Product delivery approach holding you back? Are you sacrificing quality for the sake of cost and time? It’s time to take a closer look at the Agile Triangle of Constraints (also known as the Project Management Triangle or the Iron Triangle) Refer(left most) In traditional Waterfall project management, the scope is fixed (“required”) and the project timeline and budget are inflexible. This approach is largely plan driven and often results in teams working overtime to finish all the fixed requirements in fixed time with a fixed budget As a result, the fourth constraint quality often suffers. [Refer middle image2] Customers are unhappy, teams look burnt down, there is finger pointing But there is a better way. By turning the triangle upside down (refer to right most image3), Agile product management acknowledges that cost/budget and time are fixed, but the “requirements” are variable(aka “scope”) and are prioritized. By building products with systems thinking in mind, and working closely with users and customers we can focus on the most important items in the backlog and drop or delay less critical items (at the bottom of backlog) And by writing contracts with this updated Agile Triangle of Constraints in mind, we can avoid conflicts between fixed scopes and Agile values and thinking. Let’s break free from the limitations of traditional project management and embrace the flexibility and quality that Agile can offer. Are you ready to turn the triangle upside down?

Agile Principle #1

Transform the way you approach product development with the first Agile Principle – customer satisfaction through continuous delivery! For this a Scrum Team needs to understand: 1. Why this principle is vital? 2. How it’s often neglected? and, 3. What to bear in mind while delivering products? AGILE PRINCIPLE#1: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” VITALITY OF THE PRINCIPLE → It is vital because it emphasizes the importance of delivering value to the customer → Value emphasizes focusing on outcomes and not on outputs! → Agile is customer-focused, and success depends on how well the Scrum Team meets the customer’s needs and expectations HOW THIS PRINCIPLE IS NEGLECTED? → One of the most frequent ways this principle is neglected is by prioritizing features over delivering value to the customer → This can lead to an incomplete or ineffective solution that doesn’t meet the customer’s needs WHAT TO BEAR IN MIND WHILE DELIVERING PRODUCTS? → It’s crucial to keep the focus on customer satisfaction → Prioritize delivering value:    ⇾ Early and continuously    ⇾ By listening to and incorporating customer feedback, and    ⇾ Aligning your work with the customer’s needs and expectations This will lead to successful and satisfying product development What are your thoughts on continuously delivering value to the customer keeping in mind principle#1? Please share your thoughts 😊 Check Our post

Cockburn's Communication Effectiveness - Agilonomics

Alistair Cockburn’s Effectiveness of Communication

I recently attended a 2-day training. The trainer was an expert in his field, his talk was engaging but only the trainer and I had our cameras ON. Rest of the participants barely showed their faces There was learning, but the entire 2 days looked very “businessy” and transactional. There was hardly any bonding between the 6 participants. We could have learnt more from one another and engaged in deeper  conversations if we could all see each other At times, the trainer called out an invisible participant’s name and there was no response? It felt COLD! The WARMTH was missing. The RICHNESS of “team-ness” was low It made me think deeply about the importance of face-to-face communication. Why is face to face communication so important? Agile Principle #6 states:  “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation” In simple words, it means: The Most Effective Way of Communication is Face-to-face This is best explained by Alistair Cockburn’s research on: “Effective Channels of communication model” AT THE VERY TOP RIGHT OF THE CURVE IS: 1) FACE TO FACE IN FRONT OF A WHITEBOARD Nothing beats communicating face to face with something to express your thoughts and ideas on Whiteboard, flip chart, index cards, to visibly write or express your ideas and thoughts Your ability to exchange and see – gestures, clues, body language creates richness and increases the effectiveness of communication I have additionally observed that it also leads to empathy and thus increases bonding Bonding leads to a feeling of safety and trust is easily established AT THE SPOT JUST BELOW THE TOP RIGHT IS: 2) FACE TO FACE As your richness of communication cools ( from being hot towards being cooler), the effectiveness of communication drops too Lack of a medium to express your idea simply makes one assume the other person got it The other person also inadvertently does not make much attempt to clarify a point they are not sure of AT THE THIRD SPOT, JUST BELOW FACE TO FACE IS: 3) VIDEO CONFERENCING This is the one that has come a lot into question, starting with the pandemic More often than not, I see team members, even Scrum Masters and so also Agile Coaches continue to keep their videos OFF As a result, the RICHNESS of communication drops further and negatively impacts the effectiveness of communication I’ve seen this resulting into miscommunication, misunderstanding, siloed working, lack of swarming and missed commitments Agile Champions should always be present on video and encourage their team members to do so too Exceptions should always be supported, but it needs one to stretch out of their comfort zone to set a foundation for effective communication while working remotely What has been your experience with participants’ video OFF most of the time? How did it impact communication? Check Out Our Post

Agile vs Waterfall: Methodology Comparison By Agilonomics

Agilized Waterfall vs Agile

Scrum Masters, Agile Coaches and Scrum Teams will find it useful to download and place it near their team workspace – either on digital (Miro, Mural etc.) or print and tape it on a physical wall (in office)     When working hard to quickly create stories and work items without understanding the big picture, we tend to take the Agilized Waterfall route (see top half of image), which results in: → Components that do not provide much value → They do not fit together when all done separately/sequentially → This leads to rework towards the end → Results in Frankenstein products – whose parts do not fit well → Iterative and incremental – Agile values not quite understood   (All this is represented in the top part of the image – Agilized Waterfall)   The bottom part (Agile) shows: → Early Sprints should show the shape and form of the whole product or feature → Quick prototyping means a rough version to get feedback on the shape and form → Subsequent Sprints provide a revised version of the product/feature which is now being built to quality → True value of what Agile Iterative and Incremental promised → Every stage is (potentially) usable   This visual artifact helps create awareness on what Agile promises if followed wisely and helps challenge a Scrum Team on effective ways to groom and create stories for higher value delivery   Hope you and your teams find it useful! 😊 (Note: Early versions of this artifact were all hand drawn on whiteboards, but now I have created a digital one so it can be used easily)   (taken from Amit’s Linkedin post “January 20, 2023”)

Optimizing Workforce Efficiency: Employee Utilization with Agilonomics

Effective “Utilization” of Employees

Have you heard the phrase? – “Watch the Baton, not the runners?” Translated to development work, it means:   “Focus on Idle work, not Idle workers”! (Image 1) I still come across management finding ways to extract most out of their developers by assigning them to multiple projects   The thinking is to get 100% utilization out of each worker So, Joe is made to work: 40% on project A, 30% on project B, and 30% on project C   And, this way Joe is 100% utilized! Such a mindset is flawed Here are two different ideas to explain this: Theory#1: Queueing theory and utilization (Image 2) As you can see, when queue sizes are small(optimum), utilization looms around 70% – 85%. Work continues to flow optimally. A little surge here and there is absorbed easily   With further increase in queue size, utilization shoots over to 100%.  Things slow down considerably and bottlenecks are seen   This means that if Joe is close to 100% utilized, then it will slow down the delivery or completion of all the items he is working on Furthermore, if Joe’s team mates Harry and Nancy are all (also) 100% utilized, then the team cannot handle critical items that suddenly pop up and need attention And, hence, Management needs to focus on idle work and not idle workers!   Theory#2: Context switching 40% + 30% + 30% does not add up to 100%   IT DOES NOT!   Why? Because, Joe is a human being and not a “resource” There is context switching and we know that loss of time due to context switching is pure waste! Image 3 – is from research on multi-tasking done by Clark and Wheelwright (1992) which shows that when working on more than two projects, a person’s time spent on value-adding work drops rapidly   Multitasking is an evil and really speaking, everyone is to be blamed and not only the management   I once met a developer who was asked to divide his time between 4 different projects, and as a result, couldn’t deliver to his Scrum team commitments but was fine working on the 4 projects as it brought him importance and visibility at the cost of impacting all the projects – spread across 3 Scrum Teams   It took several coaching sessions between us that helped him realize that this may negatively impact him in the long run as well and he voiced his new understanding to the management and they set him with just two projects which helped everyone!   With these two well researched theories, management and leaders need to reflect on how they utilize their people and best ways to help them be effective!   What has been your experience with over utilized workers and multi-tasking? How have you dealt with such a mindset and what have you done about it?   (taken from Amit’s Linkedin post “January 12, 2023”)

Crafting Effective User Stories: Understand Expert Advice With Agilonomics

A tip on creating good user stories

Experiment and Believe! So many times while using Agile, we get convinced with popular notions only to find that they don’t provide much value. Perhaps the people who made those notions popular were meaning something else? It happened to me years ago! One such notion I believed for years was, that, if it’s a small story, it’s a good story! I broke down work and large stories (without much thought), into smaller ones so they can fit in the Sprint. My teams worked on them, finished quite a few of them as well and we cherished the burndowns, predictability and velocity   See also; Tackling Unfinished Stories at the end of a Sprint   Then, one day I met Jeff Patton, who asked me [JP] Amit, I see you’re doing great work finishing so many stories. But, how is your team providing value? [Me] Value??, what do you mean? We deliver lots of points every Sprint, have high predictability and look at the nearly perfect burndown charts [JP] Amit, but this does not prove you are delivering high value [Me] Confused? What do you mean? [JP] Let me show you (JP Takes out a $1 bill, rips it into several pieces and hands me approximately 1/4th random pieces of the ripped bill) [JP] Now, tell me. Is that Twenty Five cents (1/4th of $1)? [Amit] Well, er…. No! [JP] Do you see, just breaking work into smaller stories to fit a Sprint isn’t providing value [Amit] Yeah, makes sense [JP] What would be a better approach? [Amit] I got it. I took out loose change. A couple of quarters, few – pennies, dimes and nickels – adding up to $1 [JP with a smile] Exactly. There’s always a way to look at work and breaking it into ways that provide value. If not each, then a few of them should be valuable     Since that time, I learnt to experiment and believe The INVEST acronym for good user stories goes this way: I = Independent N = Negotiable V = Valuable E = Estimable S = Small ??? T = Testable Mike Cohn has also redefined “S” from being “small” to “succinctly small” , which means “brief and clearly expressed” and I believe “clearly expressed” has to do with “valuable” What experiments have you done on busting Agile myths and finding out deeper meaning behind popular notions? What have you learnt from them?

Transform Your Team, Elevate Your Business!

Subscribe to the Agilonomics Newsletter and Claim Your Free Power Team Consultation Today!

We promise to keep your email address safe. You can check our Privacy Policy.

Thank you for subscribing to our Agile Wisdome - Weekly Tips!

You’re almost there! Please check your email and click the confirmation link to complete your subscription. If you don’t see the email, be sure to check your spam folder.