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

175
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
key principles in AgileOne 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.
Definition of Done path

  • 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

Signs you are doing agile WRONG

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

Join the Discussion

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

Suggested Blogs

Best ways to implement Leading SAFe 4.5 in organizations

SAFe stands for Scaled Agile Framework. This framework is mostly used by the corporate bodies which need to scale from smaller organizations to larger ones. So SAFe is also known as an enterprise-scale development methodology. This framework was coined by Dean Leffingwell. It is an ‘information base’ which is freely available, and allows you to apply Lean-Agile practices at an organization level.   Scaled Agile Framework (SAFe) is referred as the Agile framework for software development. It renders an ease of operation for the development team. SAFe 4.5 is the most updated version introduced to match the needs of the organizations. This version consists of some new features as follows:  Fastest delivery with scalable DevOps and Continuous delivery  Quick testing using the Lean Startup cycle and User Experience (UX)  Improved Portfolio performance with Lean Portfolio Management (LPM) and Lean Budgets Additionally, SAFe 4.5 allows organizations to transform from the traditional approach to Lean-Agile methodology with the new Implementation Roadmap. Implementation Roadmap of SAFe 4.5 is a guide for the organizations. Reasons to switch to SAFe 4.5: ●  The updated version of SAFe 4.5 supports the range from simplest to the most critical development environment. SAFe 4.5 is able to mould according to the organizational needs. SAFe has four new   configurations as follows:  1. Essential SAFe - an initial phase which starts just after realizing the benefits. 2. Portfolio SAFe - adds portfolio level, strategy and investment funding, guidance on Agile programs, and Lean governance as a scenario. 3. Large Solution SAFe - for building large systems that involve Agile Release Trains and Suppliers 4. Full SAFe - for the largest firms those are seeking the benefits of the Lean-Agile enterprise.   ● SAFe 4.5 works by integrating Lean Startup Cycle and Lean UX, which creates an environment to form Minimum Viable Product (MVP). It fosters quick innovation. ● SAFe 4.5 has concentrated on the feature of rapid delivery using the techniques like Scalable DevOps and Continuous Delivery Pipeline. ● SAFe 4.5 has provided a guide in the form of a 12 article series, given a name as ‘SAFe Implementation Roadmap’. Based on the Change Management technique in the organization, the roadmap       guides on the critical steps that an organization can take to achieve long term goals.  ●  SAFe 4.5 is completely backward compatible. In SAFe 4.5, you just need to adopt the advanced principles, keeping old versions in place.                                                                                                  How is SAFe 4.5 Implemented? SAFe Implementation Roadmap provides guidance to the organizations in the form of a twelve-article series which describes effective strategies and a set of activities to implement SAFe at an organizational level. Let me illustrate the 12-article series below-   Reaching the tipping point.  Train Lean-Agile change agents  Train Executives, Managers and Leaders  Create a Lean-Agile Centre of Excellence  Identify Value streams and ART’s  Create the Implementation plan  Prepare for ART Launch   Train Teams and Launch ART   Coach ART Execution   Launch More ARTs and Value Streams  Extend to the Portfolio   Sustain and Improve SAFe is a pivotal framework as it helps to achieve business benefits at an organizational level. In order to understand the outcomes of Leading SAFe implementation, organizations must embrace and understand the Lean-Agile principles. Based on the Change Management strategies in the organization, the SAFe Implementation Roadmap guides on the critical steps that an organization can follow to achieve long term goals.   
Rated 4.0/5 based on 20 customer reviews
Best ways to implement Leading SAFe 4.5 in organiz...

SAFe stands for Scaled Agile Framework. This frame... Read More

Agile Contracts or Agile Statement of Work - Must-Haves

In IT with the Agile boom, everyone wants to get into Agile Development. Be it the customers, organizations, and even developers, everyone wants to get into Agile Development. Customers want to follow Agile so that they can get to see the Product early and the changes can be incorporated without any cost. In other words, they want fixed price, variable scope. But, organizations need to be cautious in order to define how much variable scope is included in contract clauses. Organizations want to keep themselves up-to-date and follow Western culture blindly. Statements like these often come “Everyone is going Agile, why aren’t we yet?” They have to understand, every environment, every team, and every client is different. We just cannot keep on copying everyone else. Developers, of course, will have “Agile” word in their resumes which will help them grow and find jobs.   The number of agile contracts [by govt] amounts to a coat of agile paint on a giant waterfall HT @RachelProsser https://t.co/IEOPRRFFM5 — (((Dave Moskovitz))) (@davemosk) October 9, 2017 So, in desperation, companies (small or medium organizations) ONLY follow what customers say. What they end up is – with an agreement that has clauses of Waterfall model and they tell clients that we will follow Agile. These clauses might be like having fixed scope or fixed price which will be given by end of phase like requirement gathering or planning or UAT done etc. But we forget, that in Agile, every iteration has these phases and we should be targeting the contract in such a manner that it is win-win for both the parties at end of every iteration. Below figure distinguishes between the Traditional Pyramid and Agile Pyramid. Traditional pyramid has fixed scope while Agile one has the Estimated scope, to be considered while negotiating the contract.   Lawyers and Sales team need to be taught that if we are following Agile, we need to follow the terms and conditions for Agile contracting and not of Waterfall.   #agile contracts, however, are not the silver bullet: few of them delivered the right client benefits. @WC_REFSQ pic.twitter.com/8MSb0okXQ7 — Samuel Fricker (@samuelfricker) March 15, 2016 Apart from including changes like, Product Backlog (instead of BRD), Key roles in Project, the Agile methodology, below are few MUST HAVES that should be mentioned clearly in the contracts and need to be communicated to the customers, during the contract negotiation: 1. Pricing Model: It is unrealistic to expect any development project or product, to be delivered on a Fixed price basis. We all know that there will ALWAYS be changes in scope which will affect the original price. If the customer has a fixed budget, this can be managed within an Agile project by focusing on the development of high-priority items first, allowing the Customer to remove low-priority items from scope. All such issues must be taken into account when negotiating the Pricing Model for the project. Below are a few potential pricing models: a. Fixed Price per user story – Be cautious here, too long user stories need to be broken up.  b. Fixed Price per iteration – Make sure that all iterations range to similar story points. Remember, we have to create win-win for both parties. c. Fixed Price for the agreed number of features – Describe the feature well in advance. d. Time & Material (our favorite) - Customer continues to pay during an agreed-upon time period. The customer pays till a point he sees value being added. In case he sees that no value is being added, the customer stops paying and the contract ends. 2.Spikes for high-risk elements: In case the project has specific, high risk elements, e.g. technical challenges or business issues that are absolutely first timers or have never been solved before, these MUST be communicated up-front. Such Programming spikes where we attack only the riskiest coding in the project must be included in the contract. These spikes give customers a realistic view of the project ahead for the least amount of money and avoid conditions of "Fast failure". The main goal here is to uncover any weaknesses in the proposed development and hence be ready with the new plan and strategy in order to make the project successful. 3. Define Scope, but no need to mention delivery items: Product backlog defined at the high level MUST be attached to the contract as one of the appendices. Though the scope is variable and will change during the course of the project, high-level scope must be included in the contract. Delivery Items will change post discussion with PO on every iteration, but the high-level scope remains the same. Emphasize on process rather than on dates and items. This will keep the team’s mindset collaborative. 4. Settle on Definition of Done at high level: While negotiating the contract, the “Definition of Done” should ideally be defined and attached as an appendix. The clauses for “Definition of Done” that needs to be included are: a. During every Sprint Planning, PO and the development team will review the “Definition of Done” for the items that are included in that particular Sprint. b. In case of disputes, there should be appropriate resolution techniques in place between the parties.   Concluding the article by revisiting one of the values of Agile Manifesto: Customer collaboration over contract negotiation. Contracts matter to those who have signed it. Customers do face problems and you will be able to see them only when you talk to them. Once you see and understand their problems for which they have hired you to provide the solution, you need to COLLABORATE with them and get to it. Despite all the clauses in the contract, the motto should be “LET’S DO IT !!”.  
Rated 4.5/5 based on 1 customer reviews
Agile Contracts or Agile Statement of Work - Must-...

In IT with the Agile boom, everyone wants to get i... Read More

7 Deadly Sins Of The Scrum Master’s Day To Day Activities

The cultural shift to Agile and Scrum is occurring everywhere. This permits Scrum values and principles to infuse within the corporate confines. However, the mass adoption of Scrum and Agile methodologies has resulted in numerous inescapable sins.  The organizations that have adopted Scrum on a large scale conducted industry-wide surveys and have come up with 7 deadly sins of Scrum that can have a detrimental impact on project health.   Recent Agile and Scrum failure- It is best to present with facts. Collated below are the data drawn from PMI’s 2017 Pulse of the Profession Report (Version 1). The figure below shows statistics from the survey conducted to understand the most important factors responsible for Scrum failures.    Meanwhile, Agile and Scrum experts have investigated some primary reasons that trigger these failures. Here is a summarized information of seven deadly sins of project management and how to avoid these sins of project planning. Scrum Master is supposed to be an intermediary between the team members and the Product Owner. So Scrum Master should avoid mentoring the Product Owner. Scrum Master should avoid ‘command and control’ leadership style. Daily Stand-up is arranged to discuss daily tasks. So instead of taking updates individually, Scrum Master should collectively discuss what can be done to accomplish the project target. A Scrum Master should not let his team burn out completely.  Scrum Master is responsible for managing a team. It is observed that Scrum Master is taking a credit for partially finished work in the current Sprint by partially splitting the user story points. This is against the tenets of the Agile Manifesto.  Sometimes, a person who doesn’t believe in Agile and Scrum principles plays the role of a Scrum Master. Scrum Master always facilitates the Sprint retrospectives in the same stereotyped pattern. Playing the role of a Scrum Master without understanding the behaviour required to play the role of a Scrum Master.  Scrum Master solving all the obstacles for the team. Scrum Master not bringing the awareness of Engineering practices to the team. Scrum Master doing a demo during a Sprint review. Scrum Master ignoring time limits to finish a respective task.  Scrum Master allowing managers for Sprint retrospectives. Scrum Master assigning tasks to the development team. Scrum Master allowing managers to attend Sprint Retrospectives. Scrum Master trying to influence the team estimates. Scrum Master letting the team alone to commit to Sprint deliverables. Scrum Master sometimes doing planning for the team instead of facilitating them. Sometimes, Scrum Master behaves unnecessarily authoritative and over-enthusiastic about Scrum. Scrum Master acting as a sole solution provider. Gluttony, greed, sloth... The 7 deadly sins of software development by #RightScale scrum master + tech lead http://t.co/0teq8ddm — RightScale (@rightscale) June 4, 2012     Roles and Responsibilities of Scrum Master- The only way to avoid committing the deadly Scrum sins is to adhere to the basic roles and responsibilities of a Scrum Master. Below we have discussed some of the key Scrum Master roles-  Facilitates the meeting and Scrum ceremonies for the team members.  Carries out conversation between the team members and the stakeholders. Mentors teams on Scrum practices. Promotes ways for continuous improvements. Protects teams from external interruptions. Plays a key role in resolving conflicts between the team members. Appreciates when the team does well. Celebrates the team’s success Carries out face-to-face communication. Fosters team collaboration Provides coaching in Scrum adoption. Reflects Agile and Scrum values to the team. Assists the team to improve continuously. Acts as a catalyst for change. Now, let us see what a Scrum Master actually does. Here is a quick overview of the day-to-day activities of a Scrum Master-  With a fresh mind, a Scrum Master can start his/her day. SM will ask the first question to the team members- “How can I facilitate creativity for the Scrum team to improve their lives?” Attending the Scrum meeting as a facilitator for the team members, an SM just needs to listen to their project-related concerns. Consider earlier mentioned questions for further improvement. Based on the observations, decide your next step. The next step includes coaching, facilitating, managing, problem-solving, conflict resolving, etc.  Help out team wherever they lag. Educate the team members. Drive organizational change.     Last Words- The main objective of the Scrum Master is to ensure that the project is running smoothly within an allocated time and budget. The role of the Scrum Master is still a matter of discussion. Usually, people see Scrum Master as a facilitator only, but firstly he/she is a coach and then facilitator. The Scrum Master plays a key role in protecting team members from the aforementioned deadly sins of the project.  Certifications like CSM and other project related training and courses can be the best way to become laser-focused on Scrum. Choose any related certification and learn how to establish an open communication channel, make the project scope clear, protect the team from external disruptions and remove critical project blockades. 
Rated 4.0/5 based on 5 customer reviews
7 Deadly Sins Of The Scrum Master’s Day To Day A...

The cultural shift to Agile and Scrum is occurring... Read More

other Blogs