Search

We’re in Agile, We don’t Plan! Really? 

‘We are in Agile, we don’t plan!’ This was one of the most common statements in early Agile implementations. Many people in early Agile implementations took this step, knowing that they were giving up something really valuable. However, there was a natural reaction to this. This is now considered as a common myth, as planning is a fundamental aspect of Scrum. The Scrum team is committed to working towards the working software delivery with the highest value. To implement this, the team and Product Owner must have an estimate of the feature, cost for development. Intelligibly, a Scrum team is committed to working according to prioritization. Hence, Planning is an essential practice! In fact, We Plan a Lot! Sprint starts with an event called Sprint Planning The next step in planning is when the Scrum team estimates and commits to working towards the delivery of potentially shippable product at the end of the Sprint. Scrum team comes up with a detailed plan of- How much are they estimating, that they will complete within the sprint? How much will be the cost/value/hours of the tasks to be delivered? Planning happens on an everyday basis The Daily Scrum for the Scrum Team is to review the progress and refine the plan to meet the Sprint Goal. Plan on what is to be done Plan on overcoming the impediments How successful is your sprint planning? https://t.co/PTyozdqh7L @kbondale looks at 4 common challenges which impact this critical ceremony #agile #pmot #sprintplanning pic.twitter.com/2xS9a0zC34 — Agile Alliance (@AgileAlliance) March 28, 2018 Scrum Teams Own the Plan In each event, we are “Inspecting and Adapting”, Scrum teams takes the Product Backlog and come up with their plan and create their own Sprint backlog. They create it, inspect it and then adapt it for upcoming sprints and better results. Sprint Review and Retrospectives are the part of the Plan The Sprint Review is a collaborative event where the whole team gathers, reviews the product increment created, comes up with a feedback and adapts to make changes. This all is to support the planning of the next Sprint. The Sprint Retrospective is again a collaborative event to enable and plan for continuous improvement. Team plans to start, stop and continue doing the things in the current process. Progressively Refine Plans The Product Backlog should be progressively refined. It should be broken down into small user stories which can be easily implemented as we move along with the project. Eventually, the similar approach is to be taken while planning in Scrum. Let’s have a look at the advantages of having a progressively refining a plan in Scrum- It minimizes the time investment:  Planning is important, but it can be time-consuming. The time spent in estimating and planning is best viewed as an investment.  It allows decisions to be made at an optimal time:  Progressively refining the plan helps the team avoid falling into the trap of making too many decisions at the outset of the project. It allows us to make course changes:  One thing we know, when we are in Agile, that change always happens. Planning enough that we know in general but not all the aspects leaves the team with the flexibility to alter the course as more is learned.  It helps us avoid falling into the trap of believing our plans:  No matter how well we understand the expectations, and that no plan is safe from change. Progressively refining a plan reinforces the idea that even the best plan is subject to change. So, when next time you say, We’re in Agile, We don’t plan! Really? Think about it! 
Rated 4.0/5 based on 1 customer reviews
We’re in Agile, We don’t Plan! Really?  123
We’re in Agile, We don’t Plan! Really? 

‘We are in Agile, we don’t plan!’ This was one of the most common statements in early Agile implementations. Many people in early Agile implementations took this step, knowing that they were giving up something really valuable. However, there was a natural reaction to this.

This is now considered as a common myth, as planning is a fundamental aspect of Scrum. The Scrum team is committed to working towards the working software delivery with the highest value. To implement this, the team and Product Owner must have an estimate of the feature, cost for development. Intelligibly, a Scrum team is committed to working according to prioritization. Hence, Planning is an essential practice!

In fact, We Plan a Lot!

Sprint starts with an event called Sprint Planning

The next step in planning is when the Scrum team estimates and commits to working towards the delivery of potentially shippable product at the end of the Sprint.

Scrum team comes up with a detailed plan of-

  • How much are they estimating, that they will complete within the sprint?
  • How much will be the cost/value/hours of the tasks to be delivered?

Planning happens on an everyday basis
The Daily Scrum for the Scrum Team is to review the progress and refine the plan to meet the Sprint Goal.

  • Plan on what is to be done
  • Plan on overcoming the impediments


Scrum Teams Own the Plan
In each event, we are “Inspecting and Adapting”, Scrum teams takes the Product Backlog and come up with their plan and create their own Sprint backlog. They create it, inspect it and then adapt it for upcoming sprints and better results.


Sprint Review and Retrospectives are the part of the Plan
The Sprint Review is a collaborative event where the whole team gathers, reviews the product increment created, comes up with a feedback and adapts to make changes. This all is to support the planning of the next Sprint.

The Sprint Retrospective is again a collaborative event to enable and plan for continuous improvement. Team plans to start, stop and continue doing the things in the current process.

Progressively Refine Plans

The Product Backlog should be progressively refined. It should be broken down into small user stories which can be easily implemented as we move along with the project. Eventually, the similar approach is to be taken while planning in Scrum.

Let’s have a look at the advantages of having a progressively refining a plan in Scrum-

  • It minimizes the time investment: 

Planning is important, but it can be time-consuming. The time spent in estimating and planning is best viewed as an investment. 

  • It allows decisions to be made at an optimal time: 

Progressively refining the plan helps the team avoid falling into the trap of making too many decisions at the outset of the project.

  • It allows us to make course changes: 

One thing we know, when we are in Agile, that change always happens. Planning enough that we know in general but not all the aspects leaves the team with the flexibility to alter the course as more is learned. 

  • It helps us avoid falling into the trap of believing our plans: 

No matter how well we understand the expectations, and that no plan is safe from change. Progressively refining a plan reinforces the idea that even the best plan is subject to change.

So, when next time you say, We’re in Agile, We don’t plan! Really? Think about it! 

Ridhi

Ridhi Chhabra

Blog author

Ridhi Chhabra is working in the field of Project Management from last 8 years. She is also a Certified Scrum Master (CSM). She has been implementing Scrum Framework in 80% of her projects which are resulting in Successful Project Completion and Great Customer Experience. She has great Communication skills and got a proven experience in interacting with customers around the globe, across US, UK, Australia and South Africa.
She is currently working as an Executive Assistant Project Manager at KOHLEX Design India Pvt. Ltd., It is US Based Organization which is having main headquarters in California, United States and is handling operations in Hyderabad, India.


She enjoys meeting new people, traveling and writing blogs and articles. Refer to her LinkedIn for more articles.

Leave a Reply

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

Comments

Anjali

Great article

Suggested Blogs

Use Cases: How Are They Different From User Stories & How To Create Them

I could have used the word, “write” instead of “create” use cases. But I didn’t. If you know why, then you are already expert on this topic, so please do share your opinion and knowledge by adding some comments at the end of this article. If you don’t know why I consciously mentioned “create” instead of “write” then worry not. I will share my thoughts  with you and you can tell me what you think and let’s create a dialogue around it. In my previous article, I had written about user stories, and how they came into extensive usage, how they help develop better products and how they represent users’ voice at forums users don’t have access to. If you have not read that article then I would sincerely request you to read that article first as it will immensely help you in getting the right perspective about this topic at hand. Use cases in simple words are exact statements written in informal manner depicting the specific action that the user is expected to do while dealing with a particular functionality of the product. If you compare this with the definition of user stories I gave in my previous article, you will notice that here I have defined use cases as “exact statements” whereas I had defined user stories as “generic statements” written in informal manner. Why? This is because user stories set a foundation upon which great use cases are created or developed. While user stories try to explain to the engineering team about the environment, goal, role, intention of the user while he/she is going to deal or work with the software; use cases clearly define what the user is going to do here and what result is expected in crisp 2-3 lines. Use cases are one level above requirements. Below is a simple table for quick reference on differences between user stories and use cases. A simple example of creating use cases from user stories: Let us take a very simple example of a toothpaste and let’s create use cases out of it. If you want to see how to develop user story then please read my earlier article on user stories. Always remember, while it will seem easy to create use cases directly from user needs; it is full of pitfalls that might lead to missed functionality and user dissatisfaction later on, after shipping the product. So a user story would look somewhat like this: Actor  :    John, a working professional who wants to keep his teeth health and shiny Role    :    The direct consumer of this product but can influence others by his reviews of a product on his website. Expected results: After brush, John expects his breath to be fresh and teeth and gums to be health for the whole day. Now as you can see, John is a very high impact user for us [The toothpaste company] because he can affect our sales by his review of our product on his website. So meeting his needs are very critical for us. Hence the product manager, should create following user story for this scenario. Sample User Story: It is 6:30AM in the morning and John has started his morning rituals to be ready for work. Daily, his first routine after waking up is to brush his teeth with his favorite toothbrush so that he gets the refreshing feel to do remaining chores around the house and leave for work on time. He likes the way toothpaste, smoothly oozes out of the tube and rests firmly on this toothbrush without spilling anywhere. Also he likes that somehow, every time he brushes, the exact right amount of the paste comes out of the tube. It is never too much and never too little. It’s just right. He feels energized after a refreshing brush ritual and likes the feeling of freshness in his mouth after brushing his teeth. His gums feel rejuvenated, breath feels fresh as he tests it out on his palms. After spending whole day at office, where he had multiple cups of coffee, some food and some sugary items, he comes back home. While refreshing himself, he notices that his breath is still fresh and the taste in his mouth is still neutral without any traces of coffee or cheese pizza he had before. He is so pleased with the product that he has bought for himself, that he decides to write about it in his blog tonight. Now let us create some use cases out of the above user story. Use case 1: User wants to have a premium quality feel when he/she takes the toothpaste tube in their hand before brushing. Use case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. Use case 4: User feels an air of freshness in his mouth after brushing and that freshness lasts for minimum of 24 hours. The feeling of freshness is neither overwhelming nor un-noticeable. It is just mild   enough to provide a feeling of freshness while not interfering with user’s culinary habits. Use case 5: The user is pleased with the fact that the teeth and gums feel very smooth and non-scratchy after every brush. Use case 6: User is happy about the fact that even after 12 hours of intense work day routine, his breath still feels fresh And so on and so forth.  Can you think of some more use cases? If yes, do leave your comment below so that we can discuss on their validity and applicability here. Is the concept of use cases starting to make itself clear to you now and how they are different from user stories? Let us try once more. This time let us try to create use cases of this same product but for different customer base. Sample 2 of creating use cases for a product: This time, instead of a working professional, John. Let us consider Alayah, a teenage girl in high school. Actor :    Alayah, a 16 year high school student who is interested in experimenting new things with regards to body hygiene for better well-being and feeling. Her opinion is slightly influenced by the           feedback of her friends and her own personal experiences as she too likes to share her feedback with them. Role :    A direct consumer of our product and her feedback can motivate others in her circle of influence to try out our product. Expected Results: While healthy teeth and gum are the most basic of her requirements, she is bored with the same tasting toothpastes on offer these days. She wants to try out a new toothpaste that     not only provides her with best dental protection but also convinces her Mom of her ability to choose different but a better product by herself. Here, our engineering team’s task is clear. They need to create a product [toothpaste in this case], that not only impresses Alayah but also provides her with the best dental protection that she needs at her age. Her feedback carries the possibility of our product’s adoption by her immediate family members and her close friends, hence opening the market for us. The product should be unique in itself while being the best in terms of quality at cost effective price, since Alayah is not an earning member of her family. A product manager in this case, will have lot of options to think of a product here and specify to the engineering team. Let us go with one of them. Do share your versions of user stories in this case. User story: It’s morning time and Alayah’s alarm is ringing she had set last night to wake her up on time, if she needs to make it to the school without being reprimanded. She quickly jumps into the shower with a toothbrush having toothpaste on it, while her favorite song is playing out on her personal stereo. While she is freshening up, she is delighted with the fact, even after so many days, her toothpaste continues to give out the same wonderful strawberry flavor that she loves so much. And to add to her delight, her dentist gave her a big thumbs up yesterday on her teeth and gum health. Alayah has been using this toothpaste for a month now and she loves the way, the tube feels like new everyday even after so many uses. She never has to squeeze hard to get the paste out of it. One gentle squeeze and strawberry colored toothpaste gently but firmly oozes out of the tube and rests on the bristles of the brush. Earlier, she used to get lot of scolding from her mother on spilling the paste around the sink, while jumping into shower with toothbrush and paste on it. But ever since, she switched to this new toothpaste, there has not been a single spill ever since. Today, she is definitely going to tell her Mother to make permanent switch to this paste. She will recommend the butterscotch flavor to her Mom because she loves it. Wow! A wonderful experience of morning ritual for Alayah’; isn’t it? Let us create use cases for this one. Use case 1: User is delighted with the fact that tooth paste comes in a flavored version and the flavor of the paste is consistent throughout till the last drop in the tube. Use Case 2: User is experiencing a natural growth in well-being of her gums and teeth due to the regular usage of toothpaste and is certified by her dentist also. The noticeable difference comes out in 1 month of regular usage. Use case 3: The user is happy about the quality of the product and feel of it. The flow of the paste is smooth, uniform and consistent. It is firm yet soft to the right degree and grips the bristles of the       brush firmly without leaving behind any residue. Use case 4: The user is happy with the non-slipperiness of the paste as it holds wells on the toothbrush without spilling on to the floor. Use case 5: The user is going to recommend the product to her family members owing to its cost effectiveness, quality of results and number of flavored options available to choose from. In this case, the product manager’s diktat was clear. The toothpaste should be premium feeling with right amount of firmness, variety of flavored options to choose from, health improving and certified. And how did we learn properly? Because we were able to create user stories and use cases properly depicting the right user environments, their interactions with the system and their expected goals from these interactions. This is how use cases add value to the development of right product whether it is software based or manufacturing based or service based. So next time, when you want to ship to the customer, make sure you have all the right user stories targeting the right audience with complete use cases and your product will be a smash hit. This is why, I said, a product manager “creates” use cases and does not merely “write” them. Because while creating use cases, the product owner gets the feel, intent of the product that will surely be missed out if he/she is merely jotting down the requirements or use cases. In my next article, I will share with you on how requirements come out of use cases. Until then, happy creating user stories and use cases and do share your experiences with me on my email or in the comments’ section below. Thank you for your time!  
Rated 4.0/5 based on 20 customer reviews
Use Cases: How Are They Different From User Storie...

I could have used the word, “write” instead of “create” use ca... Read More

Application Of Agile Beyond (Outside) IT

Ever since its core principles have been properly formalized, Agile has been used as a go-to for software development practices. Although Agile is predominantly used as a software solution, more and more teams outside the tech industry are starting to adopt it in their daily work. Using the well-established Agile principles in non-tech environments has proven itself to be far more beneficial when it comes to team collaborations, increased customer satisfaction, getting work done efficiently and not missing a single deadline. What exactly is Agile? Agile refers to an iterative, time-boxed approach to software development. Envisioned by a group of developers looking for a more efficient way to write software, the movement has been taken from its development roots and used primarily as a project management solution. What makes Agile so efficient as a system is the approach to work incrementally from the project’s start, instead of rushing to deliver the whole package once the deadline is near. The projects are broken down into smaller bits called “user stories”, which are later prioritized and delivered in short iterations, or two-week cycles. Manifesto and common practices Many popular frameworks have stemmed from the Agile manifesto, such as Kanban, XP, and Scrum. Some of the values described by the manifesto include helping people and organization to organize and communicate their work better, getting work done instead of talking about getting work done, collaborating and staying in touch with customers and being flexible when it comes to implementing changes into the existing plan structure, etc. The frameworks themselves are made up of individual Agile practices such as Writing a backlog and prioritizing work Creating tickets which describe the amount of work needed to accomplish tasks described in the backlog Using public boards to display progress, both for the team and the stakeholders Planning the work incrementally and getting it done in a set time-period of two to four weeks Holding daily meetings where challenges, as well as work progress are discussed Including retrospective meetings after the two to four weeks’ period has passed in order to discuss all the things that went wrong and those that could be improved upon Using Agile for better communication with the stakeholders One of the best ways to communicate progress with your team and the stakeholders would be to use a prioritized backlog. This could be done on a public board such as Trello, or a private one hosted on your company’s servers. The board can list anything from current work requests, tasks that are currently in development, how long it’s going to take, etc. Allowing stakeholders to add requests to the board is perfectly fine, as long as you and your team prioritize each request and accomplish it according to the pre-set timetable. Color coding the tasks is preferable, as it allows you to separate the tasks your team can currently work on from the those going straight to the backlog. Not to mention that both the team and the stakeholders have the ability to prioritize a certain task in the backlog by democratically voting for it until it gets pushed to the top. Prioritizing backlogs allows for expectations to be communicated better and implements cooperation and collaboration between stakeholders and team members. Product development with Agile Besides software development and task delegation, Agile practices such as continuous delivery can be used to create, maintain and improve products both before and after the launch. This can be accomplished by using a two to the four-week time period to complete a draft regarding a specific product, then sending the draft to testers in order to get feedback. This feedback can later be incorporated and used to identify and flaws and further improve and work on the product before settling on the final version. Using Kanban board as a recruitment tool Although recruitment can be viewed as a rather standard process from start to completion, there are some factors which can interrupt the flow of said process. This leads to spending more time, effort and resources on getting the work done. In order to avoid experiencing any irregularities in the recruitment process flow, the recruiting team needs to be efficient and flexible while maintaining transparent communication with the other team members and stakeholders. If they don’t, any discrepancies in the workflow could easily snowball into real issues such as candidates dropping out too early and hiring costs rising significantly. These are just some of the examples how businesses can use Agile in order to improve the overall work efforts. When implemented properly, Agile practices allow teams to accomplish tasks more efficiently and communicate their progress with stakeholders and the rest of the company without any issues. Properly implemented Agile principles assure that you and your team never miss a single deadline and leave your customers unsatisfied. Even if you don’t incorporate the entire Agile manifesto, the individual practices themselves hold a tremendous value which should definitely not be ignored.      
Rated 4.0/5 based on 20 customer reviews
Application Of Agile Beyond (Outside) IT

Ever since its core principles have been properly formalized, Agile ha... Read More

Agile Transformation In A Financial Company: A Case Study

In today’s digital economy, Agile is not just confined to the IT and Development domains. Today, Financial sectors even made a headway towards implementing the Agile methodology. At the point, when any financial service decides to go Agile, it bodes well for the progress to be executed in stages.    According to one recent study made by the Harvard Business Review (hbr),  around four-fifths of the respondents said that they are successfully executing Agile methodology in the crucial part of the vital business frames. Below image will specify those crucial business functions-   Discussed below is the case study on ‘Agile transformation in a Financial services company’. It is a story of how Agile practices and principles helped a global financial company towards achieving better business agility. Company Profile The client is a global financial institution with offices spread across Asia and US. Inspired by the success stories that Agile Transformation brought, and with an objective to improve time-to-market for applications delivered this company attempted in bringing added value to both business lines and clients. They chose the Agile framework for the purpose.  While the company showed a lot of interest to bring in change, they also realised that achieving benefits with Agile Transformation would be no small deal, given the complexities of their organization structure, product management, budgeting and the existing waterfall practices that were thriving within the teams! The company realized very soon that in order to have an Agile transformation, at first, they need to build an Agile mindset!  So, the company decided to introduce some external coaches who can help in the journey of transforming to Agile ways of working. Our expert coaches worked with them to address this tricky situation using a multi-pronged, organization-wide approach to help the client teams build their positive experiences, step by step.  Engagement Type Process and Technical Coaching. Business Challenge Finding a way to respond to an increasingly changing competitive landscape, including a much larger direct competitor. Technical Challenge To find the ways to overcome the industry-related challenges with practices that help deliver high-value applications faster and frequently, leading to improved time to market. The Burning Platform Slow-down in making releases and lack of innovation. Key drivers for slow-down are- Detailed Document Requirements  Complex Quarterly planning Domain bottlenecks Developer Context Switching Phase-gate approach to Software Development Integrating Testing Cycles Goals of Transformation Frequent high-value releases, faster speed to market, sustainable transformation, Better follow-through on execution, higher quality.   Proposed Solution “Big Bang” enterprise transformation to address business imperatives for increasing customer focus and pace of innovation. This decision was due to the high degree of interdependence between the teams and the need to establish an enterprise operational framework for staffing, delivery, and governance. Sprint Cadence was common for all the Scrum Teams Common ALM Tool for all the Scrum teams Setting up the Agile Coaching Office External Coaches – Initially Coaches were mapped to BU’s and later the Coaches were assigned at the Program level which resulted in better ROI from Coaches Assess the current situation and rally leadership around an organization-wide change roadmap. Design a plan leveraging Scrum, XP, Lean Startup and other change approaches and techniques and begin execution. Started with Scrum then introduced XP in the teams. Lean startup approach was taken for Product Management which helped only in building features for which the customers were interested in the product. Adjust the plan as needed, scale out small successes, and offer recommendations for sustaining results. Help client initiate culture shifts throughout the organization Setup the Enterprise Transformation Dashboard to assess the progress and monitor the ROI from Transformation Internal Coaches Competency Development Program – To develop internal coaches for sustaining the transformation effort Launch interactive community practices within the organization for teams to learn by sharing Benefits (What Client Got) Our expert coaches worked with them to address long-standing issues delivering high-quality products to the market quickly and consistently. With our guidance, they finally saw the positive and long-lasting effects of a successful Agile transformation that enabled them to visualize— and hopefully, achieve—a nearly limitless future. Together, the Director of IT and our coaches looked at high-level strategies for reducing cycle time, improving the quality of both the existing and future code base, eliminating silos of information, demonstrating what Agile leadership looks like, and ensuring program leadership participated in the decision-making regarding changes on the technology side. A comprehensive assessment of the client’s cultural and business baseline, from which to work toward an organization-wide culture, delivery, and leadership shift Increased visibility into product delivery obstacles Drastically decreased delivery cycle time, removing an “integration window” Workflow and technical training and coaching to stand up high-performance teams Program coaching to ensure leadership decisions supported transformation goals and objectives Visible improvement in the overall quality of production code as well as test code Coaches partnered with software engineers to blend roles and set teams on a path toward becoming more cross-functional—a key ingredient in all high-yield software teams. Software Craftsmanship by using Agile Engineering Practices Delivering high-quality consumable value quickly before the relevant market opportunity is past Advising leadership and helping lead the transformation program, implementing just-in-time changes so that the company could excel in a rapidly changing business landscape Looking for opportunities to align people and processes to ensure continuous improvement Leading the coaching community in the execution of the change management program by involving company’s leadership in Coaching office operations Restructuring the thinking and organizational execution patterns so that portfolio planning and execution is used to manage key initiatives Teams also started delivering monitoring and automation frameworks that implemented continuous integration and automated deployment. Created a portfolio leadership team to manage and implement one Product Backlog with multiple Product Owners Working with HR to define the roles Facilitating conversations between business and IT helping them visualize the work being done Limiting team work-in-progress to help them focus on the products that are most important to the bottom line All parties were able to see the release from a program point of view and to truly understand that the goal of every department is to satisfy and delight customers. Our coaches also delivered several Lean Startup workshops to the product strategy innovation group. These one-to-two-day sessions are designed to help company leaders choose future products and investment opportunities. One of the biggest initial wins for the systems teams was a shortened delivery cycle. What used to take months now took weeks. Quality improved too. One of the was our coaches helped the team in accomplishing this was by introducing teams to continuous integration. Fruit of the Transformation In the wake of executing the Agile technique in the financial territories, organizations started experiencing: Delivery cycles tremendously reduced Teams implementing continuous integration, continuous deployment and some teams working toward continuous delivery Teams releasing consumable value in smaller increments of better quality faster Improved alignment between teams and between department groups Transformed company culture, extending Agility beyond software teams This, exactly, is what we achieved through our Agile transformation. This is not to say that we helped the team eliminate their existing limitations completely. Our Agile efforts essentially made every impediment visible and helped the team to work in unison towards a common goal.  Is your team ready for a similar Agile transformation?
Rated 4.0/5 based on 41 customer reviews
Agile Transformation In A Financial Company: A Cas...

In today’s digital economy, Agile is not just confined to the IT and... Read More