Search

Realizing You Are ‘WRONG’ In Agile: Relooking Agile Tenets

Solution development today involves a lot of trial and error. This results in teams doing multiple iterations in order to figure out the best possible way to make things work. But how do you determine whether you are doing the ‘right thing’? How do you ascertain whether you are going down the right path? More importantly, when do you establish that it is the right time to stop?Fail Fast, Learn FasterOne of the key principles in Agile is to ‘Fail fast & learn rapidly’. In simple terms, this means that teams should try things out, demonstrate to relevant stakeholders, get feedback and adopt the learning as early as possible. This is better identified as the ‘Plan-Execute-Inspect-Adapt’ cycle in Agile. Teams may end up doing this cycle for a particular feature or a task over and over again in an iterative manner. More often than not, this will make the solution stronger and seldom it will fail. But when do you call the feature ‘Done’?  Even so, are these stories ‘Really Done’?The definition of ‘Done’An important concept in Agile is what we call the ‘Definition of Done (DoD)’. In simple terms, it includes the circumstances under which we determine that a story or feature is completed. It helps teams determine when to move a feature card to the ‘done’ state in an information radiator.The definition of done is unique from project to project and from team to team. Before the start of the project, the team must sit together to determine the criteria that constitutes a definition of done. Below is an example of a well-crafted DoD.The feature must be elaborated and acceptance criteria defined with examplesThe solution / component must be designed, reviewed and agreed uponThe UI design is doneCode is developedCode reviews are done and passedUnit tests are done and passedQA testing is done and passedFeature is integrated into the main solutionIntegration testing is done and passedWe normally move the story to ‘Done’ state if all criteria are met. However, more often than not the feature requires changes or revisiting in the future. This may result in a new story being created in the backlog to do the necessary changes. So in reality, the story is not ‘done-done’.Achieving the done-done stateDoes the ‘done-done’ state really exist? Yes, it can happen. When the story doesn’t require any more changes and never crops up in the future then it really is ‘done-done’. The team may be required to do multiple iterations to get the solution to such a state.Obviously, this process involves a cost. Cost to the sponsor in terms of resources (human and non-human) consumed, opportunity cost and the cost of waste in the form of mistakes, defects, and throwaways.                                                                   “That which does not kill us, makes us stronger”                                                                        Friedrich Nietzsche (German Philosopher)So how long should you continue? This is like a situation where a rock climber tries to climb a perpendicular mountain. The climber will use his hands & legs, his climbing gear, and his willpower to propel him forward step by step. He will lose his grip, slip and lose ground multiple times. But he will get up and keep on climbing till he reaches the summit. But if it becomes too dangerous and if the risk is not worth it, he will bail out and stop climbing.Know when to bail outIt is important for Agile teams to know when to quit. In Agile terms, we call it ‘Pivoting’. To pivot is to understand that you are doing something wrong, quit iterating and move on with another feature. There are multiple reasons as to when you may decide to pivot.Read this article for examples of pivoting.https://techcrunch.com/sponsored/pivoting-to-success-agile-founders-who-turned-their-companies-on-a-dime/Agile teams are most probably ‘wrong’ when,The cost to implement the feature or to move it to ‘done’ state increases exponentiallyThe opportunity cost of foregoing other tasks, features or even projects is extremely largeThe ROI gets diminished fastThe end is not in sight – You keep on iterating and doing improvements but what you are doing is so uncertain and ambiguous that you are unable to see the finishing lineThe ‘done-done’ state never materializesAbove are just some reasons as to realize that you are most probably doing something wrong. Act fast to identify this and quit what you are doing. It may really be pointless for you to keep on iterating and more beneficial for you to invest your time and energy on something else.So, act wise!! Fail fast, learn fast and most importantly pivot faster!!
Rated 3.5/5 based on 4 customer reviews
Realizing You Are ‘WRONG’ In Agile: Relooking Agile Tenets 149
Realizing You Are ‘WRONG’ In Agile: Relooking Agile Tenets

Solution development today involves a lot of trial and error. This results in teams doing multiple iterations in order to figure out the best possible way to make things work. But how do you determine whether you are doing the ‘right thing’? How do you ascertain whether you are going down the right path? More importantly, when do you establish that it is the right time to stop?

Fail Fast, Learn Faster
One of the key principles in Agile is to ‘Fail fast & learn rapidly’. In simple terms, this means that teams should try things out, demonstrate to relevant stakeholders, get feedback and adopt the learning as early as possible. This is better identified as the ‘Plan-Execute-Inspect-Adapt’ cycle in Agile. Teams may end up doing this cycle for a particular feature or a task over and over again in an iterative manner. More often than not, this will make the solution stronger and seldom it will fail. But when do you call the feature ‘Done’?  Even so, are these stories ‘Really Done’?

The definition of ‘Done’
An important concept in Agile is what we call the ‘Definition of Done (DoD)’. In simple terms, it includes the circumstances under which we determine that a story or feature is completed. It helps teams determine when to move a feature card to the ‘done’ state in an information radiator.

The definition of done is unique from project to project and from team to team. Before the start of the project, the team must sit together to determine the criteria that constitutes a definition of done. Below is an example of a well-crafted DoD.

  • The feature must be elaborated and acceptance criteria defined with examples
  • The solution / component must be designed, reviewed and agreed upon
  • The UI design is done
  • Code is developed
  • Code reviews are done and passed
  • Unit tests are done and passed
  • QA testing is done and passed
  • Feature is integrated into the main solution
  • Integration testing is done and passed

We normally move the story to ‘Done’ state if all criteria are met. However, more often than not the feature requires changes or revisiting in the future. This may result in a new story being created in the backlog to do the necessary changes. So in reality, the story is not ‘done-done’.

Achieving the done-done state
Does the ‘done-done’ state really exist? Yes, it can happen. When the story doesn’t require any more changes and never crops up in the future then it really is ‘done-done’. The team may be required to do multiple iterations to get the solution to such a state.

Obviously, this process involves a cost. Cost to the sponsor in terms of resources (human and non-human) consumed, opportunity cost and the cost of waste in the form of mistakes, defects, and throwaways.

                                                                   “That which does not kill us, makes us stronger”
                                                                        Friedrich Nietzsche (German Philosopher)

So how long should you continue? This is like a situation where a rock climber tries to climb a perpendicular mountain. The climber will use his hands & legs, his climbing gear, and his willpower to propel him forward step by step. He will lose his grip, slip and lose ground multiple times. But he will get up and keep on climbing till he reaches the summit. But if it becomes too dangerous and if the risk is not worth it, he will bail out and stop climbing.

Know when to bail out

It is important for Agile teams to know when to quit. In Agile terms, we call it ‘Pivoting’. To pivot is to understand that you are doing something wrong, quit iterating and move on with another feature. There are multiple reasons as to when you may decide to pivot.

Read this article for examples of pivoting.

https://techcrunch.com/sponsored/pivoting-to-success-agile-founders-who-turned-their-companies-on-a-dime/

Agile teams are most probably ‘wrong’ when,

  • The cost to implement the feature or to move it to ‘done’ state increases exponentially
  • The opportunity cost of foregoing other tasks, features or even projects is extremely large
  • The ROI gets diminished fast
  • The end is not in sight – You keep on iterating and doing improvements but what you are doing is so uncertain and ambiguous that you are unable to see the finishing line
  • The ‘done-done’ state never materializes

Above are just some reasons as to realize that you are most probably doing something wrong. Act fast to identify this and quit what you are doing. It may really be pointless for you to keep on iterating and more beneficial for you to invest your time and energy on something else.

So, act wise!! Fail fast, learn fast and most importantly pivot faster!!

Rumesh

Rumesh Wijetunge

Chief Innovation Officer - Zaizi Limited, Chief Operating Officer - LearntIn (Pvt) Ltd., Director /

Rumesh is an IT business leader with over 12 years of industry experience as a business analyst and project manager. He is currently the CIO of Zaizi Limited, a UK based data management company heading the operations in Sri Lanka, the COO of LearntIn, a global training institute based in Sri Lanka and is also a lecturer / trainer at multiple private universities on management, IT, business analysis and project management subjects. He is the current president of the IIBA Sri Lanka chapter and is one of the most qualified and sought after trainers in Sri Lanka. Refer his LinkedIn profile for more details and to see more articles he has written on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Suggested Blogs

Product Owner Anti-Patterns You Should Be Aware Of

Product Owner plays a very critical role in the success of Agile/Scrum implementation in an organization. The entire effort of transforming teams with Agile ways of working is bound to fail if the role of a Product Owner is not understood clearly. Listed below some of the anti-patterns seen while the person is playing the role of a Product Owner in a team- Busy or Missing Product Owner, not being part of the development team Working software demo to the PO during Sprint Review Expressing the backlog in Technical user stories instead of focusing on business-related user stories Writing detailed user stories (no scope for negotiation) Questioning the estimates given by the Dev Team Not having a clear acceptance criteria for every story Too large user stories Not questioning the customers while collecting the requirements Not allowing the Dev Team to work on Technical Debt Not validating the customer’s idea before implementing the idea Not allowing Development Team members to talk with the Stakeholders directly Not empowering the Proxy POs Lack of vision on the product being developed Delivering more features than valuable features Not having well-defined prioritization mechanism in delivering user stories Changing priorities or requirements during the Sprint No single Product Owner, required governance missing in case of multiple POs Missing in Scrum Ceremonies Relying on mail communication for answering queries from Dev Team No emphasis on Quality Treating estimates as deadlines Instructing team on what needs to be done, acting as a Manager Expecting user stories to be created by team, considering SM and PO to be there only to review the stories Pushing team to do extra work for finishing everything forecasted during Sprint Planning Holding the team responsible for any rework post feedback from stakeholders during Sprint Review  Not showing interest in answering team queries for clarifications after Sprint planning Task monitoring Not coachable by Scrum Master Unable to prioritize the work Consistently changes priorities during the Sprint Accepting partially completed PBI’s Allowing dev team to change the Story points of a user story post implementation Not saying “No” to the stakeholders and allowing the product backlog to grow in size   There's nothing more paralysing than a Scrum team with a bad Product Owner! The characteristics stated above lead to nothing but a Product Owner “Fishbowl” where new ideas and innovative thoughts pertaining to Scrum processes find no entry at all.  The Product Owner  is... The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. It’s a one-person role that brings the customer’s perspective of the product to a Scrum Team.  The Product Owner is responsible for:  Developing and maintaining a product vision and market strategy Product management  Ordering and managing the Product Backlog  Involving stakeholders and end-users in Product Backlog refinement and backlog management  Alignment with other Product Owners when needed from an overall product, company or customer perspective.  #MostPopular in 2017: "Product Owner Anti-Patterns — 31 Ways to Improve as a PO" https://t.co/sryCdoxVKu pic.twitter.com/q5Sxj9kF6F — Stefan Wolpers (@StefanW) 22 December 2017 A GREAT PRODUCT OWNER…  Grasps, shares and spreads the product vision: A great Product Owner acts as the client's voice (also called a proxy-client at times) and makes a product vision together with the stakeholders. Each choice is taken on account of the product vision. This guarantees sustainable product improvement, gives clearness to the development team and expands the chances of product success definitely. Understanding the customer’s goals: A great Product Owner truly understands the customer’s goals with the product and is able to outpace its expectations. After all, pleasing the customer is the ultimate goal. Is a good decision maker: A great Product Owner is an authorized person to take product-related decisions. It may take some time to support his/her decisions, but this is an essential condition for an economical pace of the development team. Manages the product backlog: A great Product Owner comprehends that the product backlog should be in sequence. Priority, risk factor, quality, getting to learn and dependencies are all considered and balanced with each other. Prefers one-to-one communication: A good Product Owner believes in one-to-one communication to convey information. User stories are used as a medium of conversation. Knows modeling techniques: A great Product Owner has a knapsack full of worthful modeling techniques. Actually, the PO has an idea about when to apply a specific model. Based on the model application he/she drives the project success.  Shares experiences: A great Product Owner offers experiences with peers. This may be inside the organization, and outside it. Additionally, courses and meetings are the great approaches to share experiences and garner information. Furthermore, recording your lessons can be significant for other Product Owners. Claims user story mapping: A great Product Owner should ace the idea of user story mapping. It is a method that enables you to add a second dimension to your backlog. The visualization empowers you to see the master plan of the product backlog. Keeps an eye on functionality: A successful Product Owner keeps an eye on functional as well as on the non-functional aspects of the product. The motto of the Product Owner is to exceed the quality expectations the customer and enabling functionality that provides value to the product. So, the functionality is the main focus of the Product Owner.  Is knowledgeable: A great Product Owner has a deep product knowledge and comprehends the technicality. Larger products might be difficult to understand and scale. In this case, the PO should know the formula to solve the large queries.   Comprehends the business domain: A great Product Owner knows the ins and outs of his domain. A product should be built with a clear idea of every aspect being dealt with. This not only entails understanding the organization and paying for the development but also being aware of the current market trends. No matter how great your product is, shipping it after the window of opportunity closes is a waste of time and barely of any value.  Acts on different levels. A great Product Owner is capable of acting on different levels. These levels are popularly denoted as- strategic, tactical and operational. At the board level, a PO should know how to demonstrate the product strategy. Thereafter, he should create a strong support at middle management and facilitate the development team to cope with their daily challenges.  Knows the 5 levels of Agile planning. Within Agile, planning is done continuously. Every product needs a vision (level 1) which will provide input to the product roadmap (level 2). The roadmap is a long-range strategic plan of how the business would like to see the product evolve. Based on the roadmap, market conditions and status of the product the Product Owner can plan releases (level 3). During the Sprint Planning (level 4) the team plan and agree on Product Backlog Items they are confident they can complete during the Sprint and help them achieve the Sprint Goal. The Daily Scrum (level 5) is used to inspect and adapt the team's progress towards realizing the Sprint Goal.  Is available. A great Product Owner is characterised by his availability to the stakeholders, customers, development team and most important, the Scrum Master. This helps important questions to be answered quickly and valuable information to be provided on time. The Product Owner always makes sure that his availability never becomes the bottleneck of the progress of the development team.  Is able to say 'no'. A great Product Owner knows the best time and way to say “no”. This indeed is a difficult trait to master. While it is easy to give any new idea or feature the nod, there is a flip side. Good backlog management necessitates creating a manageable product backlog with items that will mostly get realized. Appending non-productive items to the backlog will only create false expectations.  Acts as a "Mini-CEO". A great Product Owner basically is a mini-CEO for his product. He has a sharp eye for opportunities, focuses on business value and the Return On Investment and acts promptly on all possible risks and threats. Every growth aspect such as size, quality, market share of the product is taken into consideration.  Knows the different types of valid Product Backlog items. A great Product Owner can clarify the fact that the Product Backlog consists of more than only new features. For example, technical innovation, bugs, defects, non-functional requirements and experiments, should also be taken into account.  Takes Backlog Refinement seriously. A successful Product Owner spends sufficient time refining the Product Backlog. Backlog Refinement is essentially the act of adding detail, estimates and order to items in the Product Backlog. The result should be a Product Backlog that is granular enough and easily understandable. On an average, the Development Team spends no more than 10% of their capacity on the refinement activities. There is no such prescribed approach. The Product Owner can also involve stakeholders and the Development Team in backlog refinement. Each for a valid reason. The stakeholders are given the opportunity to state their expectations. The Development Team can clarify functional and technical implications. This will ensure a holistic understanding and enhance the quality of the Product Backlog considerably. Consequently, the opportunity to build the right product with the desired quality will also increase.  Concluding Thoughts: A Product Owner is indispensable for a functional Scrum team. He not only bridges the gap between the development team and the client but also ensures a streamlined product delivery. Ill-defined Product Owner roles and some of the critical PO anti-patterns are some of the impediments many of the Agile organizations are battling at present. The only long-term solution to such persistent issues is a clarity of PO roles and a proper understanding of the end-to-end Scrum processes. 
Rated 4.0/5 based on 7 customer reviews
Product Owner Anti-Patterns You Should Be Aware Of

Product Owner plays a very critical role in the success of Agile/Scrum... Read More

Project Manager Vs Product Owner

Traditional waterfall projects had the Project Manager unquestionably at the helm of the ship. Today, as more companies migrate toward agile, the role of the Project Manager has become redundant. Agile advocates team work — wherein there are self- organizing teams, and much of the responsibility that was earlier shouldered by the Project Manager is shared by the group. In an agile environment, the Product Owner owns the product, the Scrum Master owns the process and the team works together toward fulfilling the tasks. In a traditional project, the Project Manager holds all the cards and owns the entire project. Today, Project Managers need to redefine their responsibilities in the agile context, and depending on their inclination frequently take on the mantle of the Product Owner or ScrumMaster. There has been much heated debate on this topic in many online Scrum forums, with differing results … but research shows that there is no definitive answer that squarely references the PM to the PO. While Scrum rejects the role of a Project Manager per se, there are many who believe that this role has been reframed to include the two roles of a Product Owner and a ScrumMaster. The ScrumMaster is by definition a servant leader. The Product Owner, by definition, is the person who represents the business stakeholders and keeps the team focussed on the product itself. As a Product Owner, his or her job is to tell the team what to do…but not how to do it. The ‘how’ is decided by the team members themselves. And that, in a large part, sums up the difference between a Project Manager — who needed to spell out the Hows, Whats and Whys — and the Product Owner, for whom only the definition of the problem…or the What… is all-important. In Scrum, there is no single management position. And that’s where the beauty of Scrum, and perhaps its efficacy, lies. Scrum teams are self-managing, and when each member of a Scrum takes on some responsibility, the project has a much higher chance of success.
Rated 4.0/5 based on 20 customer reviews
Project Manager Vs Product Owner

Traditional waterfall projects had the Project Manager unquestionably ... Read More

Career Path Of A Scrum Product Owner

A scrum product owner has the dual capability of foresight and the decision-making power to make a project successful. A Scrum Product Owner will work on the product for its entire life-cycle and hence will have an idea of how things need to be prioritized, managed and executed. This decision-making and communicating power capability can be obtained by undergoing a CSPO certification program and the experience will enable the candidate to access a wide range of career opportunities. Listed below are some of the great career paths that await a Scrum product owner. 1. Business Analyst: Product Owners are well-suited for a business analyst profile as they have adequate knowledge on how to handle the business requirements and supplement with analysis and thus enable better decision-making. This knowledge can be used to improve the business and hence being a business analyst would be a great career path out there to choose from, after being a product owner. 2. Project Manager: The role of a Project Manager is another great career path that is available to a product owner. The candidate will be involved with project planning and management. This role is usually available after being a business analyst, and there are many companies out there who look out for Project Manager Candidates with the Scrum certification. 3. Product Manager: The other direction you can choose is the product management side where you will get to focus on expounding requirements for a product based on strategic requirements and product-market fit. The path to this position can be prolonged as it requires you to be a business analyst first and also have a Master of Business Administration Degree (MBA). But once pursued, this will work on to be one of the best career paths. 4. Chief Executive Officer (CEO): Senior Product Owners have a great probability of becoming the CEO of a company. Though this requires a lot of experience, perseverance and demands lots of time. The experience gained from being a product owner is a valuable asset as you get to learn about how to make the product successful, how to enliven the team, how to be dedicated, how a high return on investment can be achieved, how to engage the customers, etc. All these qualities are what is being looked for in a CEO, for managing the whole company and for taking it towards a great success path. So the product owners have got a great career prospect here! So go ahead! Take a course in CSPO (Certified Scrum Product Owner), become a great product owner and expose yourself to a wide range of sumptuous career paths.
Rated 4.0/5 based on 20 customer reviews
Career Path Of A Scrum Product Owner

A scrum product owner has the dual capability of foresight and the dec... Read More