Search

Think Big - Act Small: A New Way For Agile Teams?

We all love planning. And planning big is what we do. Don’t you have great visions for your life when you start a brand new year? You identify a great big list of New Year resolutions and set yourself some goals to achieve within the year. When you are soon after your primary education you research and end up planning big on what academic and professional qualifications to achieve and within what timeframe.Even Google has become a part of your elaborate planning! So much so that, even before you key in your exact query on planning, it readily comes up with so many suggestions!Basically, even the search engine giant has got one thing right about you. You always plan big!!But, Agile tells us to think big and not to plan big. Thinking big has a deep meaning. When you embark on a journey you need to think and clarify the bigger picture of the whole journey. For example, if your employees embark on their annual trip you need to set a bigger picture for the staff on the objectives of the trip. Is it merely a journey to somewhere far away, chill and come back the next day? Or are your objectives for the staff to bond a bit better, communicate and build team spirit that can create a positive atmosphere at your workplace?Think big for your Agile projects as well. Identify the bigger picture for the solution that you are trying to develop. Spend time to understand the business outcomes that the solution is trying to achieve and know the key principles for high-performing Agile teams.Is it a solution to improve efficiency?Is it to improve collaboration and convenience?Is it to increase profitability and market share of the organization through better reach?Think about where the solution will be deployed and who will be using it. How will the solution get operationalized and what impact would it have on the Stakeholders. Try to draw forth as much information as possible to identify above aspects of the solution.Thinking big is not only from the business perspective. Think big in terms of the entire solution landscape, the context and the entire solution architecture as well. There is no need to identify a comprehensive solution design and architecture right at the inception. But always keep the entire solution and the key components in mind when you do the design. Make it and evolving architecture by building in the capability to plug in components as and when required. Technology and client needs are changing and hence adaptability is a key.Though you think big you must always make sure to take small baby steps at a time. Acting small means to identify the smallest piece of work or task that needs to be done to make sure that the project progresses forward. Think of a driver that has met with a car accident and is confined to a wheelchair. He will have to go through hours of physiotherapy just to be able to stand up on his two feet again. Then he will start taking one step at a time in his quest of walking again.Concepts that can be measured while thinking Big1) Working in a team incrementally and iteratively  The product size determines how many increments it will take to complete the work. The notion behind working in iterations is to get the status of work at the end of the long stage. e.g. For Development stage, it may take two week cycles over the period of 3 months.Working in increments shows doing a group of tasks at a time, then adding another group in the next iteration. At the end of each iteration, you can show the completed task to the client. This way helps to get early feedback, can update the changes, test out ideas, and deploying before the timeline.  Dedicated teams are nothing new to creative land, what is different, is that it means that they are really dedicated to the project full-time, rather than working on a bunch of other projects at the same time.Now, we know in agency land, this can be hard to pull off, since we have a tendency to move resources around as needed, because of skill-level or other resource issues.Now, you can still manage teams as a dedicated resource by, keeping all of the related projects with one team. All of the pieces are then prioritized (working with the client to decide). This gives you big idea on building a successful Agile team. The big idea is that you work in a dedicated team, and at the end of each iteration, or time period, you have something of value to show the client. In the first time period, the client decides what should get worked on, and with each iteration you add things in the order they are of value (incrementally), and then repeat the process through multiple interactions till the work is done.2) Change should be embracedThe client asks for change, team produce a change, and charge for it. In traditional methodology, teams were preventing change. For software development projects embracing the client’s changes early and updating before the deployment date can be very impactful.Planning plays a crucial role in Agile. Though your end product is outstanding, how to deal with the market demands and conditions is critical part for embracing opportunity and change.In Agile methodology, the Stakeholder and the team prioritize and chooses the highest-priority work to be completed during that iteration. Being flexible at an iteration stage, the client should not ask for the changes during this time. But your team can maintain the scope-of-work by working in 1 or 2 week intervals. If any changes needed then those changes can be pushed to the next iteration. There are some characteristics of new Agile teams that includes limit to what team can accomplish during a fixed period of time. Things can go out of the scope, resources and costs can still change.Agile software development projects are exactly like that. You first think big to identify all components of the solution and the tasks that the team members need to work on as Product backlog items. These are initially at a really high level – may be as epics.Now you can groom the stories and break them down into smaller stories or tasks that can be assigned to individual team members. Remember the 1-2-3-4 rule? One or two implementation team members should complete a story or task taken to the sprint within 3 to 4 days. Acting small will help the team develop something visual and demonstrable as soon as possible so that it can be sent for feedback as early as possible.Think big, act small are 4 simple words with a great deep meaning which leads in creating new Agile teams. For an Agile team to become a successful robust team these are key principles for high performing Agile teams that can be preached and followed diligently.So, do you think big but act small?
Rated 4.5/5 based on 3 customer reviews

Think Big - Act Small: A New Way For Agile Teams?

349
Think Big - Act Small: A New Way For Agile Teams?

We all love planning. And planning big is what we do. Don’t you have great visions for your life when you start a brand new year? You identify a great big list of New Year resolutions and set yourself some goals to achieve within the year. When you are soon after your primary education you research and end up planning big on what academic and professional qualifications to achieve and within what timeframe.
ResearchEven Google has become a part of your elaborate planning! So much so that, even before you key in your exact query on planning, it readily comes up with so many suggestions!

Basically, even the search engine giant has got one thing right about you. You always plan big!!

But, Agile tells us to think big and not to plan big. Thinking big has a deep meaning. When you embark on a journey you need to think and clarify the bigger picture of the whole journey. For example, if your employees embark on their annual trip you need to set a bigger picture for the staff on the objectives of the trip. Is it merely a journey to somewhere far away, chill and come back the next day? Or are your objectives for the staff to bond a bit better, communicate and build team spirit that can create a positive atmosphere at your workplace?

Think big for your Agile projects as well. Identify the bigger picture for the solution that you are trying to develop. Spend time to understand the business outcomes that the solution is trying to achieve and know the key principles for high-performing Agile teams.

  • Is it a solution to improve efficiency?
  • Is it to improve collaboration and convenience?
  • Is it to increase profitability and market share of the organization through better reach?

Think about where the solution will be deployed and who will be using it. How will the solution get operationalized and what impact would it have on the Stakeholders. Try to draw forth as much information as possible to identify above aspects of the solution.

Thinking big is not only from the business perspective. Think big in terms of the entire solution landscape, the context and the entire solution architecture as well. There is no need to identify a comprehensive solution design and architecture right at the inception. But always keep the entire solution and the key components in mind when you do the design. Make it and evolving architecture by building in the capability to plug in components as and when required. Technology and client needs are changing and hence adaptability is a key.

Though you think big you must always make sure to take small baby steps at a time. Acting small means to identify the smallest piece of work or task that needs to be done to make sure that the project progresses forward. Think of a driver that has met with a car accident and is confined to a wheelchair. He will have to go through hours of physiotherapy just to be able to stand up on his two feet again. Then he will start taking one step at a time in his quest of walking again.

Concepts that can be measured while thinking Big
Concepts that can be measured while thinking Big1) Working in a team incrementally and iteratively  
The product size determines how many increments it will take to complete the work. The notion behind working in iterations is to get the status of work at the end of the long stage. e.g. For Development stage, it may take two week cycles over the period of 3 months.

Working in increments shows doing a group of tasks at a time, then adding another group in the next iteration. At the end of each iteration, you can show the completed task to the client. This way helps to get early feedback, can update the changes, test out ideas, and deploying before the timeline.  
Working in a team incrementally and iteratively  Dedicated teams are nothing new to creative land, what is different, is that it means that they are really dedicated to the project full-time, rather than working on a bunch of other projects at the same time.
Now, we know in agency land, this can be hard to pull off, since we have a tendency to move resources around as needed, because of skill-level or other resource issues.

Now, you can still manage teams as a dedicated resource by, keeping all of the related projects with one team. All of the pieces are then prioritized (working with the client to decide). This gives you big idea on building a successful Agile team.
 
The big idea is that you work in a dedicated team, and at the end of each iteration, or time period, you have something of value to show the client. In the first time period, the client decides what should get worked on, and with each iteration you add things in the order they are of value (incrementally), and then repeat the process through multiple interactions till the work is done.

2) Change should be embraced

The client asks for change, team produce a change, and charge for it. In traditional methodology, teams were preventing change. For software development projects embracing the client’s changes early and updating before the deployment date can be very impactful.
Change should be embracedPlanning plays a crucial role in Agile. Though your end product is outstanding, how to deal with the market demands and conditions is critical part for embracing opportunity and change.In Agile methodology, the Stakeholder and the team prioritize and chooses the highest-priority work to be completed during that iteration. Being flexible at an iteration stage, the client should not ask for the changes during this time.
 
But your team can maintain the scope-of-work by working in 1 or 2 week intervals. If any changes needed then those changes can be pushed to the next iteration. There are some characteristics of new Agile teams that includes limit to what team can accomplish during a fixed period of time. Things can go out of the scope, resources and costs can still change.

Agile software development projects are exactly like that. You first think big to identify all components of the solution and the tasks that the team members need to work on as Product backlog items. These are initially at a really high level – may be as epics.

Now you can groom the stories and break them down into smaller stories or tasks that can be assigned to individual team members. Remember the 1-2-3-4 rule? One or two implementation team members should complete a story or task taken to the sprint within 3 to 4 days. Acting small will help the team develop something visual and demonstrable as soon as possible so that it can be sent for feedback as early as possible.
Cost of change curveThink big, act small are 4 simple words with a great deep meaning which leads in creating new Agile teams. For an Agile team to become a successful robust team these are key principles for high performing Agile teams that can be preached and followed diligently.

So, do you think big but act small?

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

What is Agile Planning & Agile Planning Levels?

What is Agile Planning? Agile planning is focused on getting the answers to simple questions like - what is to be built, when will it be completed, how much will it cost and who should be involved etc. The project managers also explore hidden dependencies for various activities to minimize the idle time and optimize delivery period. Agile planning revolves around measuring the velocity and efficiency of an Agile team to assess when it can turn the user stories into processes, production-ready software, and quality product delivery. The ultimate goal of Agile planning is to have a clear picture of project vision, production roadmap with sprint schedule, and business interests. To simplify the things, Agile planning can be stipulated of different levels - product vision; product roadmap; release; iteration; daily commitment.  Level 1: Agile Planning For Product Vision – Five Tips:  Agile planning starts with product vision creation ensuring that strategies are aligned properly and the development team spends its time on creating the right valuable product. The product vision guides the team members for the shared goal like a lighthouse. The product vision statement tells about ‘how the product supports organization’s strategies.’ You can simplify the process of Agile product vision development by making it a four-step exercise – development, drafting, validation, finalizing. The following five tips will help you to get the most out of it:  Product vision should deliver the unique feel of ownership to keep you motivated.  Validate your product vision with all the stakeholders, Scrum team members, users etc. Develop the product vision iteratively & incrementally with the scope to make it better over time.  The product vision pitch should address all the key concerns of different stakeholder groups pertaining to quality, product goals, competition, longevity and maintenance needs etc.  Focus your product vision on the values for users and customers not merely on the most advanced technology.    Level 2: Agile Product Roadmap Planning– Five Tips:     An Agile product roadmap is a plan that describes the way the product is likely to grow; it also facilitates for learning to change. To succeed in Agile management, you need to have a goal-oriented roadmap as it provides crucial information about everyday work by the team. As a powerful Agile management tool, it helps to align all the stakeholders and to estimate sufficient budget for quality product development as per schedule. Creating effective roadmap is often a challenge because changes occur unexpectedly in an Agile environment; however, the following five tips will help you plan the most effective roadmap:  Do all the necessary prep work including describing & validating the product strategy. To know more about ‘Product strategy in the Agile world’, visit - https://svpg.com/product-strategy-in-an-agile-world/ .  Focus your product roadmap on goals, benefits, objectives, acquiring customers, removing technical debt and increasing engagement etc.  Let your product roadmap tell a coherent story about the likely development of a product. To simplify the task, you can divide the product roadmap into two parts- internal product roadmap and external roadmap. The internal product roadmap is focused on development, service, supporting groups, marketing, sales etc; while, the external roadmap is focused on prospective & existing customers.  Keep the product roadmap simple and realistic to make the features understood by everyone concerned.  Make your product roadmap measurable; so, think twice before adding timelines and deadlines.  Level 3: Release Planning – Five Tips:   In Agile landscape, the release is a set of product increments released to the customer. The release plan defines how much work your team will deliver by the mentioned deadline. Release planning is the collaborative task involving Scrum master (facilitates the meeting), Product owner (shares product backlog view), Agile team (provides insights into technical dependencies & feasibility) and Stakeholders (the trusted advisors). The following five tips will help you in effective release planning:  Focus on goals, benefits, and results.  Take dependencies and uncertainties into account. Release early but don't release just for the sake of scheduled releasing. Only release the work that is 'Done'. To know more about ‘Definition of Done (DoD)’ in Agile, plz visit -  https://www.knowledgehut.com/blog/agile-management/definition-of-done-use-in-agile-project .  Each release process has the scope for betterment. Continuous release process improvement helps you deliver more values for the product. 5 levels of #Agile planning ... and the DoD. #ProjectManagement #pmot https://t.co/qTalLiJS1S by John Goodpasture pic.twitter.com/dlWuMTnC8e — JoseAntonio Martinez (@MartinezBuenoJA) November 14, 2016 Level 4: Iteration Planning – Five Tips:   The iteration planning is done by holding a meeting, where all the team members determine the volume of backlog items they can commit to deliver during the next iteration. The commitment is made according to the team's velocity and iteration schedule. The following five tips will help you in effective iteration planning: Span the iteration planning meeting maximum up to 4 hours.  The planning meeting is organized by the team and for the team; so, everyone should participate.   Avoid committing anything that exceeds the historical team’s velocity. Keep time for ‘retrospectives’ in the past sprints before planning for the next one. To know more about ‘Agile retrospective’, visit - https://www.agilealliance.org/glossary/heartbeatretro/.   Follow the four principles – prepare, listen, respect & collaborate.  Level 5: Daily Commitment Planning– Five Tips:  Like many other planning activities for Agile management, the daily commitment planning also needs the synchronized partnership of teams. The daily planning meeting is focused on completing the top-priority features. The 15-minute standup meeting facilitates face-to-face communication on individual’s progress and impediments if any. The following five tips will help you in progress-oriented daily commitment planning:  Keep it around the task board.  Start on time regardless of who is present or not. Let each team member go through the questions like - what he did yesterday, what is his plan for today, and, is there any impediment?.  Use ‘Parking Lot’ for the unresolved issues. The purpose of daily Agile-Scrum planning is to let the team members know about ‘being done’, ‘needs to be done’ and ‘hindrance if any’. Anything out of this scope should be listed in ‘Parking Lot’ to be dealt later.  Do preparation ahead of time. The team members should know ‘what they need to share’.  Conclusion:  Agile planning levels are not time-consuming or complex; instead, these help product owners focus on the right group of professionals and the product development stage. The strategic Agile planning for different levels reduces considerable time, effort, and cost that is otherwise invested in repetition, correction, and last minute meetings etc. 
Rated 4.0/5 based on 43 customer reviews
What is Agile Planning & Agile Planning Levels?

What is Agile Planning? Agile planning is focus... Read More

Transitioning to Agile Course: Five Success Factors

Transitioning from a waterfall process to an Agile framework like Scrum can be a daunting task. However, you can make the effort a whole lot easier if you have a good idea of what needs to change – beyond getting rid of waterfall – if you were to take the plunge for your organization. I have found that there are five broad success factors that need to be addressed in order to successfully transition to Agile. Without addressing these factors, you may be able to make a transition but the viability of the effort is likely to be short-lived. Below is an illustration of the five success factors: Although all five success factors are essential, Culture has a greater impact overall… Technology In this context, we are referring to technology as any process, tool or material that helps solve a problem. Typically, this is the element companies tend to focus on first – and unfortunately often ends up being the only factor they focus on.  Software tools like ScrumWorks, Mingle or  Jira’s Greenhopper are good examples. So is frameworks like Scrum or XP; they all help enable teams to be successful and solve a problem. Unfortunately, by ignoring the other factors, transition efforts suffer. Organizational Design We use the term ‘design’ here rather than ‘structure’ as this refers not only to the organizational structure of the organization, but also the physical (architectural) outline.  If an organization is very hierarchical with several layers of decision-makers, your transition efforts will be challenging. Also, if resources are located in remote locations or have a clear ‘office preference’ where open space and collaboration are frown upon, you will have a hard sell on your hands. But don’t ignore this – you will lose a significant piece of Agile’s potential if your company’s organizational design is not addressed. Leadership This can be one of the most important factors; leadership holds a lot of influence as they ultimately pay the bills and can allocate money, time or people to your transition efforts. Does leadership actively sponsor and support your transition efforts? Do they lend their influence to help Agile grow and prosper in your organization? Without leadership support, any transition effort is going to be difficult to sustain. If senior leadership is not quite on board yet, look for other influential leaders at other levels. However, if you find that you have zero support within the company’s leadership, I would categorize this as fatal to your transition efforts. People Ultimately, your organization’s employees are the ones that are going to make this work or not. If employees thrive on working in the basement alone, abhor team work or are not open to new ideas and ways to work, you are going to have a tough battle on your hands. Resistance is inevitable as change is tough for everyone, but you’re going to need some energetic, motivated ‘agilistas’ in order for any Agile transition effort to work. Look for people with energy, enthusiasm and low egos – you need to be humble in order to complete a successful transition. Culture Which leads us to the last – and most influential – success factor: culture. The organization’s culture has typically been developed over many years, so this is hard to change. But if you recognize what you’re dealing with, you are more likely to design a response to fit the situation. Agile thrives in a collaborative, team-based culture in which transparency is obvious and people are not afraid of making mistakes or letting other people in the organization know if there are problems (in fact, ‘failing fast’ is a virtue as it reveals concerns early on in the project). If you find that your organization extols values in stark opposition to Agile principles (i.e. command and control, fear of failure, ‘CYA’ mentality, etc), this is something that needs to be addressed if you’re going to have any hope of a successful Agile transition. In future Agile posts, we will look into the success factors further and discuss approaches for transitioning to Agile in a way that fits your company’s unique situation.
Rated 4.0/5 based on 20 customer reviews
Transitioning to Agile Course: Five Success Factor...

Transitioning from a waterfall process to an Agi... Read More

Incomplete Stories & Tasks in an Agile Sprint

Have you ever encountered a situation such as above? I am sure you have and I am sure that you experience this often. So, how do you deal with it? Does the managers in your company make a big issue out of it? Is it a situation probed intensely by the product owner and even the Scrum Master who is the team’s protector? You need not worry. Below is a discussion on incomplete sprints, better known as ‘Spillovers’, and on how to best deal with them. Spillovers & DoD – The definition Simply put, a spillover is a backlog item that has failed to meet the criteria defined in the Definition of Done (DoD) for the project team. It is important to note that the DoD is defined for the entire project and is applicable for any user story. For example a team may decide that the DoD for a user story is for it to be elicited, groomed, analyzed, designed, UI / UX designed, coded, unit tested, functionality tested, integrated and regression tested. Any story not ticking all these boxes may be marked as not done. Well, not always!! The team may decide that some of these criteria is not applicable for certain stories during sprint planning and those should be evaluated accordingly. Trouble with Spillovers? Spillovers normally surface during Sprint Demo & Retrospective meetings and often give trouble to Scrum team members and product owners during sprint planning. It is the responsibility of the PO to mark a user story as done by going through the DoD criteria. Then only should the story be moved to the ‘Done’ column on your JIRA board. Sometimes the POs end up scratching their heads as a result of poorly defined DoD’s or just pass stories on to Done state just ensure progress. Similarly, during planning teams end up spending a lot of time discussing about these spillover stories and do extensive planning for these unfinished user stories. Spillovers are common phenomena for any agile team. But it is important to analyze the root causes for these spillovers if this happens often.  Common reasons for spillovers Below are some common root causes for unfinished work- Problems with DoD – The DoD was not accurately defined, and you find that out later in the sprint. This results in the argument around marking the story as ‘done’. Overestimation of work for the sprint – The team becomes over ambitious and commits to much more than they can handle. Larger chunks of work eating up on time of other stories. – This is actually not a big issue. Story point estimation is a relative estimation and has no link to time needed in hours. Hence, this overrun of time may happen often. Unforeseen scenarios– There may be situations where a team member becomes unavailable due to sickness, other work commitment or personal commitments. Other situations related to team members not be able to access code repositories due to various environmental elements may also cause delays. Change in priorities – PO may decide to change priority of stories mid sprint or stories may even become higher priority with technical limitations. As a result, stories may not be completed and may get spilled over to subsequent sprints. Dealing with spillovers So it is important to devise strategies on how to manage such unfinished work. Below are some recommendations on how to do so. Again, this is not rocket science but the application of some common sense to make things work. It is important to review the process followed by the team during the sprint retrospective session. This session can be used to identify the root cause for spillovers and to discuss options available to mitigate it. It is important to note that the cause for most delays may be common and thus the team must understand the factors related to delivery delays to quickly move on to discuss other aspects important for project success. The team must discuss on the future of the user story that got spilt over. The PO must decide whether the story is still on high priority or not.  If yes, then simply move the story forward to the next sprint. You have already decomposed the story to the most granular level during grooming and it is just a matter of getting it done. Again, if the story was done partially it is important for the team to discuss the amount of work remaining to mark the story as done. This analysis may actually result in the creation of a new user story with a new acceptance criteria, a completely new DoD and a brand new estimation. If not on priority, simply move the story to the bottom of the product backlog. The story will get evaluated for priority during backlog grooming and be moved up or down the backlog as relevant. I previously wrote an article on capacity planning for agile teams. It makes sense for the Scrum Master to understand the availability of the team for the entire duration of the sprint and plan the amount of work that can be taken up accordingly. For more information on capacity planning and how it may help avoid spillovers refer here Some more logical things to do is to dedicate more time for planning. This may be done by defining a proper goal for the sprint and to ensure that all user stories are aligned with this particular sprint goal. The scrum team may also set aside some buffer time for unplanned work which will give the team some breathing space just in case a story runs for more than planned. So in conclusion, spillovers are to be managed properly. You may never be able to completely eliminate it from your projects. But with proper management and planning, you can reduce the number of times it may occur and be able to reduce its impact.  
Rated 4.0/5 based on 20 customer reviews
Incomplete Stories & Tasks in an Agile Sprint

Have you ever encountered a situation such as abov... Read More

other Blogs