Blocked Columns on Kanban Boards Obfuscate Workflow and Undermine Effectiveness
The Boards in Azure DevOps are a powerful tool that your teams can leverage to enable transparent visualization of the current state of value delivery. However, the inclusion of Blocked columns can stealthily erode the very foundations of efficiency these boards are meant to uphold. By obfuscating the state of work-in-progress and breeding a culture […]
Sculpting the Product Backlog: A Delicate Balance Between Lean Inventory and Future Readiness
Unravel the art of sculpting an effective Product Backlog in our latest blog post. Discover the significance of a lean inventory reflecting your product’s unrealized value, and the necessity of anticipating the future without clouding the backlog. We explore the essence of continuous reflection in calibrating the backlog, dissecting surprises, and turning them into invaluable insights. Just as sculptors chisel away to create masterpieces, learn how product managers can craft a Product Backlog that’s lean, comprehensible, and future-ready, thereby optimizing ROI for stakeholders.
Rethinking Product Backlog: Navigating Through the Weeds of Complexity
The Product Backlog is a critical asset in Agile product development; it represents a dynamic lean inventory of everything the product needs. For those of us navigating the multifaceted landscape of product development, there is often an impulse to seek an ideal structure for the Product Backlog. The familiar hierarchy of Initiative->Epic->Feature->User Story->Task/Bug is a […]
Navigating the Future with a Fine-Tuned Product Backlog
🔍 Discover the underpinnings of a transparent and promising future in Agile Product Management! My latest blog post explores the indispensable role of an ordered Product Backlog that is coherent, refined, and rightly sized.
How Usable Working Products Are Your Ultimate Weapon Against Risks
🚀💥#UsableWorkingProduct: Your Ultimate Weapon Against Risks in Agile💥🚀 ⚠️ Ever wondered why some Agile projects falter? Is your fortress of documentation crumbling against the relentless tides of market change? 🌊 Here’s the secret sauce – It’s all about Usable Working Products! 🎯🔧 Too many Agile teams are trapped in the illusion of progress without creating shippable products. It’s time to unleash the secret weapon against risks – deliver increments that users can interact with, validate, and provide feedback on! 🛠🚀
Professional Agile Leadership – Evidence-Based Management (PAL-EBM) Course with Certification
𝗣𝗿𝗼𝗳𝗲𝘀𝘀𝗶𝗼𝗻𝗮𝗹 𝗔𝗴𝗶𝗹𝗲 𝗟𝗲𝗮𝗱𝗲𝗿𝘀𝗵𝗶𝗽 𝘄𝗶𝘁𝗵 𝗘𝘃𝗶𝗱𝗲𝗻𝗰𝗲-𝗕𝗮𝘀𝗲𝗱 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 (𝗣𝗔𝗟-𝗘𝗕𝗠) is delivered over two half or one full day(s) and includes the industry recognised 𝗣𝗔𝗟-𝗘𝗕𝗠 𝗮𝘀𝘀𝗲𝘀𝘀𝗺𝗲𝗻𝘁. It shows how leaders can guide their teams toward continuously improving customer outcomes, organizational capabilities, and business results. EBM focuses on customer value and intentional experimentation to systematically improve an organization’s performance and achieve its strategic goals.
What is Taylorism, and why Waterfall is just the tip of the iceberg!
Martin HinshelwoodJan 18, 2021·11 min readFor many people the traditional project management methodologies (see PMI / PRINCE2) are the root of the problems that birthed Waterfall. I assert that this is the tip of the iceberg. These methodologies are just a symptom of a greater problem that has its roots in the changes made during the industrial revolution. These changes, while they generated great amounts of wealth and many jobs around the world, dehumanised work and destroyed the essence of value and discovery that brought humanity to where it is now. It created processes that turned people into little more than sophisticated robots and enshrined that thinking into the very core of how we do things.These practices, which spread like cancer, have been seeded around the world by the Master of Business Administration (MBA). These practices have been calcified in the malignant bureaucracy that can be likened to an iceberg that may very well sink your company.Reviewer(s): Russell Miller PSTWhat is Taylorism, and why Waterfall is just the tip of the iceberg!Prior to the industrial revolution, goods were made in small cottage industries and people worked close to their home. Customers were local, and both the producer and the consumer knew each other well. Mastery in ones chosen profession was paramount and rewards for the master craftsman were earned through increased money, or more time to pursue other interests.When the industrial revolution came along, massive mechanisation was needed to produce goods at scale. However the technology of the time was unable to automate at that scale, so the only available “machines” were people. When, in pursuit of higher production volumes, you take away from people their autonomy, mastery, and purpose in your pursuit, you take away their soul. When you take away the essential elements of rewarding work, people become mindless automatons.Frederick Winslow Taylor is a controversial figure in management history. His innovations in industrial engineering, particularly in time and motion studies, paid off in dramatic improvements in productivity. At the same time, he has been credited with destroying the soul of work, of dehumanizing factories, making men into automatons.Vincenzo SandroneTraditional management practices were born out of the disengagement of the workforce. With the outcome controlled and repeatable, management focuses on best practices and incentivising people to work faster and harder. They wanted to remove thinking from the work since thinking creates ideas, and ideas create deviations from the pre-defined optimal way of working.The thinking goes like this: Ideas and innovation from your workers were a risk to your business and thus must be eliminated. We need to remove thinking!When you remove thinking from work and turn people into automatons:People don’t care about the work — and your workforce disengages, so their interest in the work and empathy for the customer also wains. Your workforce doesn’t care about the work, and workers primary concern is no longer the success of the company. They are instead concerned mainly with the output of their repetitive operation and maintaining or increasing their levels of remuneration.People become replaceable cogs — Indeed the company comes to see an uneducated workforce who just do as they are told as easily replaceable resources. They don’t have any discernable skills and the company has many people waiting for those jobs that can be easily slotted in. The company now no longer cares about the individual and they become resources to be allocated and replaced.These two outcomes result in an erosion of trust between the workers and the company.These working practices have resulted in:This was the advent of the age of bureaucracy.If you think about the school system in most countries, especially if you are over 30; we all sat in rows, did the same thing at the same time, were forbidden from talking, and teachers used incentive based learning! I assert that there is no difference between this and the treatment of factory workers. The modern school system was developed during the industrial revolution to train factory workers.The end result is that many people have been trained from an early age to be factory workers. However very few of us will end up as factory workers today. We will more likely be office workers, solving cognitive business problems.Is Taylorism ingrained in the way we work today?If you are lucky enough to work in one of the small numbers of companies that have already transitioned away from departments, hierarchies, headcount, work breakdown, best practices, and individual bonus systems then you are fortunate, or maybe selective.Most people are not so lucky.The trouble with departments & hierarchiesIn the days of the industrial revolution, employees were perceived as untrustworthy. Managers were needed to tell workers what to do and how to do it. As our organisations grew we needed managers to manage the growing number of managers and incentivise those managers to increase productivity in our employees through any means that they could.“ Put people in competency based groups “The Scientific Management MethodUsing the Scientific Management Method the Business Owners should identify each problem domain (e.g. Sales, HR, Marketing, Engineering, Testing) and come up with the “one true way” to do that work within the domain. The Business Owners can then hire managers and workers that will be trained in the “one true way” of doing that work, and minimise deviation from the Business Owners control.And so we created departments so we could centralise training and knowledge on a single topic. If you were hired for sales, you ended up in the sales department: Completely disconnected from the makers, the designers, and the implementers. There would be no need for communications between Sales and the other departments since we have planned all of their work methods and need only follow the script.As the world became more complex and sales became a creative endeavour the imposed departmental isolation model became a negative impact. Sales personnel started making decisions in the complex world only taking sales concerns into account; that, by design, was all they knew. Creation and delivery had no bearing on closing deals, so they were ignored except in the most general terms. To close the deal and get ones bonus sales personnel only needed to get the customer to sign, it mattered not if you could actually deliver.Often the result of this relationship was animosity between the departments, and unhappy customers when either quality, money, time, or features had to suffer.An example of this was the Microsoft Azure Platform. Salespeople were measures and bonuses paid based on the amount of Azure that customers bought. This measure resulted in salespeople pushing output over the outcome. They sold millions of dollars of Azure to companies that never used it. This resulted in unhappy customers and declining sales. Customer failed to see the value in what they were buying.Then Satya Nadella (CEO of Microsoft) changed the measure for Sales from the output based measure to one based on the customer’s outcome. Salespeople were no longer bonused based on how much they sold, but instead on how much a customer used. This change was revolutionary for sales of Azure. They were no longer focused on the short term ( to get executives to sign) but on a much longer engagement model with customers. It became critical to encourage customers, with direct help, to move towards DevOps practices. Microsoft provided ( and continued to provide) consultants and coaches to help create better outcomes for customers. This has paid off hugely for Microsoft as they are now the largest cloud computing provider despite starting late.This seemingly small change in how people are measured changed behaviours greatly. Many salespeople left Microsoft as a direct result as they were only interested in the short term, and not the long term investment in customer success.Microsoft also restructured how Sales personnel work so rather than it being one huge department each product was responsible for their own Sales, Marketing, Engineering, and Support. With Sales now a skill within the Product teams instead of a separate organisation, Product Groups can leverage the combined knowledge of all disciplines to encourage customers to use more azure.How will you break siloed departments within your organisation and move towards more holistic and aligned Product teams that can deliver value to your customers?The trouble with Best PracticesIn the days of the industrial revolution, employees were perceived as unskilled. Business owners needed to create standard operating procedures for every facet of work within each problem domain. The work of the time existed within the simple space. The work being performed may by categorised as “simple”, with relatively few unknowns. Manufacturing created a large volume of pre-defined work in a low variance environment where the outcomes of the work were known before the work was performed. Output was the only control and correlated directly to profitability.“Create standard practices and train workers in those practices”The Scientific Management MethodSince there was a low variability in the work we could plan it all out beforehand, and simply follow that plan. We could hire managers to maintain order and compliance with defined methods, and treat employees as simple replicable cogs.Business owners created best practices for creating products and expected everyone else to follow them.As the world became more complicated and we were able to create automation using machinery with software to control it. The simple, low variance work could be automated. This allowed workers to focus on more complex cognitive tasks, but the management practices more suited to repetitive, low-variance work persisted.Although the work had changed, the belief in predictive planning prevailed. There was a belief that if people just followed the detailed work breakdown and Gant chart, then everything would be fine.Best Practices, Centers of Excellence, and Innovation Labs are all constructs of the Tayloristic practices designed for simple, low-variance work. These practices seek to exert more control over the new complex modern world of work.Even in the simple, low-variance domain, the old Tayloristic practices based on the Scientific Management Method destroy the soul of work. These practices create workers that hate the work, their managers, and the company.We need a new way!In the simple world, the Toyota Production System is the poster child of innovation and discovering new ways of working. Optimizing the workspace and creating good practices became the job of the employee and they were encouraged to periodically stop and reflect on how to do things better.In the complex world of Sales, Marketing, and Software Development we also needed new ways of thinking that would power the same ideas from Toyota and Lean into the high variance world of complex cognitive work. This was the birth of the Agile movement with the Scrum Framework (1993), the Agile Manifesto (2001), and later Kanban (2004).Instead of coming up with best practices, we realise that there are only good practices for the situation at hand. A good practice, today might not be quite so good tomorrow, and thus we need to be a lot more flexible. No longer is the business owner (or manager) the best person to define these practices since they are no longer close to the problem.We are uncovering better ways of developing “products” by doing it and helping others do it.Agile Manifesto, 2001The best people to make decisions and define practices are those with the most information. Today that is the people doing the complex cognitive work.We need to accept that our practices are imperfectly defined. With this in mind, we need to push responsibility for defining those practices down to the people doing the work: they have the information required to make better decisions about which actions are more likely to yield the desired outcomes.The trouble with Task and Bonus systemsIn the days of the industrial revolution, employees were perceived to be lazy. It was perceived that revenue was lost due to this lazy, malingering workforce and so business owners needed to figure out how to minimise downtime and maximize output. Since managers were keeping people with the same ability in the same group, and planning everyone’s work, the one remaining thing to be controlled was the worker’s focus.“Reduced wage based on expected low performance and bonuses for increased output”The Scientific Management MethodManagers used various methods to incentivise workers to work harder and faster:The Task and Bonus system is by far the most prevailing practice today, however, all of these systems were designed to create the same outcome and have a similar negative impact on workers.Developed by Henry Gantt, the Task and Bonus system is an augmentation to the Taylor Differential piece work system and was intended to pay workers a low wage, since we expect them to have low performance, and then have a bonus that takes them to a potential high wage.Taylor, Gantt, and Emerson all created different “Carrot and the Stick” approaches to management.There are other ways to try and incentivise people, rather than just how they are remunerated:The idea that you need to dangle a carrot in front of the employees in order to get them to work more efficiently is a logical outcome of the practices we have been discussing throughout this article.There have been many studies done at universities around the world on financial incentives for employees. All of them agree that higher pay and bonuses only resulted in better performance when the tasks were basic mechanical tasks. More money works for tasks that have a pre-defined set of steps with a single answer.If a task involved even a small amount of cognitive skills, decisions making, or creativity then more money resulted in lower performance. This is contrary to the common understanding of wage incentives.If you are managing people you should pay them enough so that they feel that they are compensated fairly and not struggling to meet their basic needs. You should pay them enough to take the issue of money off the table.There are three key areas that Leaders need to focus on that will increase the performance of your workforce:If you and your business only focus on profits without valuing your employees need for autonomy, mastery, and purpose then you may end up with unhappy employees and poor customer service. I don’t know about you, but I do not do my best work when I am unhappy!The trouble with TaylorismThese Tayloristic practices worked well for employers during the industrial revolution. However, even factory work has progressed in the shadow of the Toyota Production System and the lean movement. People are no longer cogs in a machine that can be replaced at a moments notice. Each employee brings a unique skill or ability to your product discovery and product development story. That story will be unique because of it. These Tayloristic practices kill ingenuity, focus, and enthusiasm.Foster ingenuity, focus, and enthusiasm and stop killing it with Taylorism. Bring the soul back to the work.Originally published at https://nkdagility.com on January 18, 2021.
Sprint Goal is an Immediate Tactical Goal
In the The Evidence-Based Management Guide we talk about the Intermediate Strategic Goal and I likened that to the Product Goal in the 2020 Scrum Guide. If we also think of each Sprint as a tactical move towards fulfilling that Product Goal then the Sprint Goal becomes an Intermediate Tactical Goal that moves us towards […]
Story Points & Velocity are a sign of an unsuccessful team
Martin HinshelwoodJan 4, 2021·6 min readStory Points and velocity have been used for many years in the Scrum community and have been engrained so much in the way that things are done that most folks believe that they are part of Scrum. The accepted wisdom is that Scrum Teams are supposed to use User Stories, Story Points, and Velocity to measure their work.Accepted wisdom is wrong!Reviewers: Steve PorterVelocity and Story Points are not ScrumThere are a number of things that we collectively believe are required to do Scrum, and these have been perpetrated by the long-running perseverance of trainers teaching to the lowest common denominator and keeping things as simple as possible. There is the general consensus in the trainer community that folks that attend Scrum training are not smart enough to do anything else. However, if you go have a look at the Scrum Guide and see how many time common things that you believe are mandated in Scrum are referenced:Velocity: 0Story Points: 0Burndown: 0User Stories: 0Original Estimate: 0Bug Count: 0Actual Completed: 0The answer to all of these searchers is zero! These are complementary practices that may or may not work within the bounds of your organisational complexity, and all of these are an indication to me that your organisations are only just starting its evolution towards agility.Managing the unknown is hardIt’s ok for a team to start with Story Points and Velocity. There are many things that change when a team moves from the traditional project management practices of the past to the empirical practices of the future, and sometimes we need to pick our battles. One such battle is that of story points and velocity and in fact all of the gubbins surrounding it.Perhaps you need to appease other parts of the organisation that are not yet ready for change. Perhaps you have a long journey and this is just somewhere to start.Story Points & Velocity can be a good starting point!I am not saying that there is no value in Story Points or Planning Poker. When a team is just starting out they need to keep things simple and iterate towards better outcomes. We often start from typical traditional practices and Planning Poker becomes a good learning point. Story Points use rough sizing as a way to analyze the work and break it down.Because really, the scores are made up and the points don’t matter. It’s the conversation that is a valuable thing. The shared understanding that the participants get by having some way to know when they don’t understand the same things. That is awesome.However, agile teams try to use Story Points and Velocity for future predictability and this is a fallacy. While I would be OK with a team using it for a while, if an Agile Team is still using Velocity and Story Points after they have 5 or 10 sprints under their belt then I would have serious concerns about their ability to adapt to change and their sincerity towards that change. What I mean is that they just don’t understand their work or its nature; This is what I mean by immaturity, and not that something else is a sign of maturity!Indeed as the Scrum Team using Story Points really has no consistent reference they are just shooting in the dark the same as they were before.While they have gained an understanding of the goals, they still don’t have an understanding of the predictability and thus no confidence in their predictions. We need concrete data to build trust with stakeholders that we know what we are talking about.We need confidence!Velocity was a way to assert that confidence with a plot of our delivered story points, and along with some clever calculations we asserted that we were likely to deliver about 20 story points. This was such a wholly improbable assumption that the vast majority of Scrum Teams talk about “carry-over” points and quiz me about how to represent that. Do you re-estimate and stick it on the backlog, does it move to the next sprint?Scrum Teams have been basing their confidence to stakeholders on an agreed consensus that cant be compared and is susceptible to any change from the makeup of the team from the estimation room.We need confidence!Confidence Through TransparencyConfidence is gained by truly understanding the uncertainty of delivery and factoring it into our projections. How sure are you that you will be able to deliver? No really! what is your statistical level of confidence?In the empirical world where more is unknown than known, we don’t plan all of the work (it will change) and we cant tell you when things will be done.Except when we can!The Increment is the Confidence of Transparency of the Future — If we have a Scrum Team then I should be confident in saying that we will have a usable increment at the end of every Sprint. If that is true, then we can have 100% confidence that we can deliver the output from the last Sprint. It works, and it’s done!The Product Backlog is the Confidence of Transparency of the Future — Since we have a backlog that has been ordered by the Product Owner, who is accountable for maximizing the value delivered I can be confident that what we have Done represents the most valuable things that we could have done.With both of these being true we can have 100% confidence that we have the most valuable items that the business needs to be completed and ready to deploy. Every additional Sprint just adds to the quantity of value.Using a cycle time scatter plot we can assess and find our confidence levels, and even create a Service Level Expectation, that allows us to measure progress against.You can use this range of confidence levels to determine your current levels of predictability, and monitor the effect of changes that you make to your system on it. If you have an 85% confidence level of 16 days and you’re on 2-week Sprints then you have a problem.This data is not hard to collect and find a full list of awesome metrics in the Kanban Guide for Scrum Teams from Scrum.org.Originally published at https://nkdagility.com on January 4, 2021.
Story Points & Velocity are a sign of an unsuccessful team
Story Points and velocity have been used for many years in the Scrum community and have been engrained so much in the way that things are done that most folks believe that they are part of Scrum. The accepted wisdom is that Scrum Teams are supposed to use User Stories, Story Points, and Velocity to […]