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

166
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

Leave a Reply

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

Suggested Blogs

Best Practices of Scaled Agile Framework - Agile Management

The enterprises have many different frameworks and methodologies to choose from once they decide to adopt the ‘Agile’ approach for project/product development. Designed by the Scaled Agile Inc, the Scaled Agile Framework (SAFe) is an Agile software-development framework. Earlier, the Agile development methodologies were used on a trial basis for various projects at an enterprise level. The development team experimented in making an efficient Agile method suitable to work in their environment. This resulted in evaluation of methods that worked and that didn’t, which ultimately led to the development of various frameworks and strategies for the adoption of the Scaled Agile Framework. Within the last few years, the Scaled Agile adoption has become popular amongst many enterprises. The two most important responsibilities of management are measuring improvement and ROI. The management needs to choose a solution that best equips with their business model and speed up the delivery and release phases. With these benefits coming handy, more and more professionals are practising lean and Agile methods and implementing it in the enterprises. The Scaled Agile Framework is a highly structured and is mainly used in larger enterprises and is primarily used to for agile development. It is an increasingly popular framework that has been successfully implements in enterprises. The nine principles of SAFe include as follows: 1. Taking an economic view 2. Applying systems thinking 3. Assuming variability by preserving options 4. Incremental built with fast and integrated learning cycles 5. Building the foundation of milestones on objective evaluation of working systems 6. Visualising and limiting WIP, managing queue lengths and reducing batch sizes 7. Synchronising with cross-domain planning by applying cadence (timing) 8. Establishing deep-rooted motivation of knowledge workers 9. Decentralising the decision making There are three levels in SAFe, and they’re as follows: • Team All the SAFe teams are the Agile teams consisting of 5–9 people working in 2-week scrums. They have skills to define, develop, test, and deliver value using XP (Extreme Programming) methods. Unlike the traditional development scrums, they work in collaboration. • Program At Program level, 5–10 SAFe teams consisting of 50–125 persons create an “Agile Train Release” comprising of stakeholders and development teams. They put in sync their iteration boundaries and facilitate delivery of integrated working systems every 2 weeks. The SAFe defines the Agile Release Train (ART), which in every 10 weeks (5 iterations) delivers a Potentially Shippable Increment (PSI). The PSIs provides a steady cadence (timing) for the development cycle. • Portfolio The lean–Agile budgeting mechanisms are budgeted by a portfolio, which is a collection of value streams. The portfolio management requires program management, investment funding, strategy, and governance. A portfolio is associated with the enterprise strategy in terms of strategic themes. Epics that define large-development initiatives are captured and analysed by a portfolio Kanban system. There are business epics that are customer facing, and then there are architectural epics that are technology solutions. How the practices of the Scaled Agile Framework benefit the organisation? SAFe is considered as a framework based on Agile Development, Lean, and Systems Thinking, which has gained worldwide recognition throughout the large corporations and enterprises. Following are the benefits of adopting the Scaled Agile Framework for your organisation: 1. SAFe allows implementation large team programs and portfolios Initially, the organisations adopt Agile approach and experiment it by its implementation with small teams. After gaining moderate success with small teams, often the organisations would try to increase the size by aligning various teams, programs, and various departments in an organisation to promote collaboration and efficiency in development and shipment of the product. By identifying the key Agile functionalities, Lean and Systems Thinking that scale well, SAFe addresses all these issues. 2. SAFe outlines a consistent approach for planning, execution, and delivery of value It becomes difficult for large organisations when numerous Agile teams are involved, because the teams might operate on different cadences (timing), or might use various Agile frameworks, or might rely on varying tools for managing the Agile lifecycle, or the teams might have adopted different technique practices. SAFe makes use of ART (Agile Release Train), which collaborates various Agile teams on a consistent cadence for every 8–10 weeks. It is known as a Program Increment (PI). This enables the teams of the organisations get together and uncover, plan, and address dependencies of the teams and the risks that might arise. All the teams of ART make use of best practices such as the Scrum-of-Scrums during each PI. At the end of every Project Increment, the ART does the analysis of what was done in the past 8–12 weeks. 3. SAFe addresses roles and responsibilities across Team, Program, and Portfolio levels Adopting and implementing Agile causes a drastic change across the organisation, which can raise questions regarding the current and new functions. SAFe addresses all these questions across the various levels. 4. SAFe provides a framework to bring consistency in strategy and alignment to the program and team levels In an organisation, maintaining an overall alignment with the vision and strategy is often a challenge faced by enterprise-scale software development. It becomes difficult to arrange various business departments with similar strategies, and if that is achieved, the problem still persists to communicate that strategy at the team level. SAFe provides an architecture to implement Agile, Lean, and Systems Thinking consistently to various levels in an organisation. 5. SAFe improves product development lead times SAFe is a well-documented approach that applies its principles, benefits, and values to the wider enterprise. More and more large corporations have understood how to scale Agile to lessen the time required for product development and improve the release time of their product compared to their market competitors. SAFe provides an extensive set of functionalities that can be applied in an enterprise to successfully scale Agile.
Rated 4.0/5 based on 20 customer reviews
Best Practices of Scaled Agile Framework - Agile M...

The enterprises have many different frameworks and... Read More

The Many Roles a Scrum Master Plays

Putting together the two words “Scrum Master” might seem unusual if you’re new to Agile. Who in the world would want to be called a Scrum Master? Actually, there are some people who dedicate themselves to this role. What exactly is that role?  I’m glad you asked! This article will explain the role played by an all-powerful Scrum Master. Let’s start by looking at some of the key functions.  What Exactly is Scrum? For those of you who are not familiar, Scrum is a management process that is designed to slice through complex projects. Teams are formed to get a handle on new requirements and technologies, boosting their ability to deliver work projects in an efficient manner. Scrum itself is the actual framework of efficient team collaboration. The concept is actually quite simple, but the name is what confuses so many people. In short, Scrum is a team equipped with advanced knowledge given the task of collaborating on complex products.  Scrum Expert Another big question that you might be asking yourself is, ‘Who on Earth decided to make it Scrum?’ Well that discussion is for another time, but you can check out the Scrum Alliance website for more information.    A Scrum Master  is the leader of a Scrum group, being responsible for the entire team’s use of the methodology. They are also called a Scrum Expert by some people. The expert role is performed in a number of different ways. Scrum Masters facilitate meetings, make sure each member of the team knows their role, and ensures that the team has the correct tools.  It’s important that a Scrum Master catches what their team members are doing right and provides positive affirmation while showing them how to improve even further.  Obstacle Cleanser Scrums need to be scrubbed clean of obstacles. Okay puns aside, a Scrum Master should identify anything that might be slowing the team down and remove them from the equation. Obstacles can range anywhere from slow response times to outdated hardware.  Scrum teams are dependent on the leader’s ability to plan out their path so that they can focus solely on the tasks in front of them. In short, the Scrum Master ensures that the team can work efficiently.  Information Dispenser Another pivotal role is that Scrum Masters must constantly dispense information to project stakeholders and members of the team. They are the gateway of communication between the two. There are several tools that a scrum will use to achieve success, including backlogs and burn down charts. Scrum Masters are tasked with using these tools to communicate to various outside sources.  The Facilitator The term “facilitate” itself means to “make less difficult and help move forward.” A Scrum Master is expected to make tasks as easy as possible for their team. This can be done in a number of different ways such as provide the right tools, help set expectations and communicate an overall vision. Scrum Masters are always at the forefront of the scrum.    Coach Coaches have a deep understanding and appreciation for their goals and are equipped with the knowledge to help guide their team to victory. For most scrums, victory would be the successful launch of a new, complicated project. They should be excitable and have the ability to spread this excitement throughout the team, just as sporting coaches do.   Scrum Masters must fill all of the roles that we have mentioned in this article, but sometimes even more might be expected of them. They must be 100% dedicated to these roles in order for the scrum to successfully achieve the overall vision of a business.   
Rated 4.0/5 based on 20 customer reviews
The Many Roles a Scrum Master Plays

Putting together the two words “Scrum Master” ... Read More

Agile and ITIL: Friends or Foes?

Today, many IT organizations are expanding their IT businesses using ITIL (Information Technology Infrastructure Library) and other valuable industry frameworks for ITSM (IT Service Management). They are focussing on improving their service quality. In addition to quality, companies are trying to build agility, with the emergence of new technology and methodology like Agile Software Development.  Recent reports from ITSM.tools emphasized upon the factors that organizations measure during work in IT industry. The following image shows the statistics of the aspects, as measured by the organizations. Even after the use of these methodologies and technologies to speed up delivery, IT operations were not able to get on with the fastest delivery rate of IT services. So industries carried out many discussions regarding the combination of ITIL and Agile- Is it possible that both can coexist within an organization? Can ITIL and Agile play major role after merging service quality with agility and speed? Will Agile and ITIL together becomes friends or foes? The article has tried to address this as precisely as possible.  ITIL provides a framework for the governance of IT from the business and customer outlook. ITIL is referred as the best practice framework for IT service management (ITSM). It focuses on continuous measurement and improvement in the quality of the IT services delivered to the customers. According to the ITIL Practitioner course, ITIL includes 9 guiding principles as follows: Focus on value Design for experience Start where you are Work holistically Progress iteratively Observe directly Be transparent Collaborate Keep it simple Agile is a set of processes for software development which fulfills customer requirements and solutions from the cross-functional teams. Companies need to adopt the key points from the Agile Manifesto to achieve Agile ITSM. The key points are as follows: Individuals and Interactions over processes and tools Working Software over comprehensive documentation Customer Collaboration over contract negotiation Responding to Change over following a plan. If these Agile practices are matched with the 9 principles of ITIL, you will find some striking similarities. ‘Working software’ is an equivalent to ‘Focus on value’- which means develop the right things, the valued software can be used by the customers. The ‘Keep it Simple’ principle clearly explains how close ITIL and Agile are! This principle suggests to act quickly and deliver quality, which is the same as ‘Responding to change’.    One of the main hurdles in the integration of Agile and ITIL is the truth that ITIL follows sequential framework, whereas Agile is an iterative approach where Minimum Viable Products (MVPs) are constructed and updated in a very short period cycle. This may create instability. However, businesses and their clients look for stable and agile IT services. DevOps can be the solution for it. It is a more endurable approach for bringing these two contrasting approaches to enable stability and agility (Development and Operations), together. DevOps is based on the combination and communication between Development (Dev) and IT Operations (Ops). DevOps provides technical practices to produce a software. The goal behind DevOps technology is to automate an application delivery and workflow of the processes (planning, design, implementation, testing).  In future, there will be a lean, fast and agile IT service management. According to Gene Kim, thought leader and co-author of The Phoenix Project- “Patterns and processes that emerge from DevOps are the inevitable outcome of applying Lean principles to the IT value stream […and] ITSM practitioners are uniquely equipped to help in DevOps initiatives, and create value for the business”. Essentially, considering the diverse perspectives, Agile and ITIL can exist without some major conflict. Agile and ITIL can very much go hand in hand, because this combination allows IT organizations to have a new culture called, Agile ITSM. ITIL will offer a framework for stable and quality-assured service rapid delivery, whereas DevOps will ensure to provide the continuous stream of improvements. Due to the alliance of Agile/DevOps and ITIL principles, Agile ITSM can provide guidelines for service and the speediest delivery in an Agile way!   
Rated 4.0/5 based on 20 customer reviews
Agile and ITIL: Friends or Foes?

Today, many IT organizations are expanding their I... Read More

other Blogs