Agile frameworks like scrum can only serve agile project management and agile product development to some extent. But when it comes to apply agile across the entire organization, a different approach and framework needs to be used.
The scaled agile framework is used as enterprise level agile framework by large organizations (Multi-National Corporations). It addresses the enterprise level portfolios, programs and projects management approach and guidelines.
The scaled agile framework (SAFe) consists of its prescribed principles, values, processes and templates. The roles used in the framework upto the level of projects are same as scrum. The product manager, scrum master and scrum team remain, but it also adds more roles and people to take care of scaling agile for the entire organization.
The scaled agile framework was created in the last decade and it has gained popularity in past 5-6 years. The adoption and usage increased as SAFe still complies with many of the agile scrum mindset and methods. SAFe is also adopted largely as it helps the entire organization adoption and not just some pockets and divisions. It covers the entire portfolio, programs and projects including embedding important parts of lean, Kanban and agile way of working across the organization.
The scaled agile framework prescribes adherence to 5 core values and 10 principles for it to work smoothly in the organization,
Core Values of SAFe Framework,
1. Alignment – Alignment of priorities, purpose and goals across the portfolio ensuring right sizing of resources to fulfilling portfolio needs.
2. Built-In Quality – Ensure clearly articulated “Definition of Done” at all levels of work. Ensuring quality is given importance for the first-time right delivery.
3. Transparency – Full transparency on progress and updates across the entire portfolio.
4. Program Execution – Focus on efficient execution and delivering results that will create business value.
5. Leadership – Lead the organization and team with lean and agile leadership mindset. Ensure the core values and principles of lean and agile are well understood and embedded across entire organization.
Key Principles of SAFe Framework,
1. Take an economic view – Operate with lean and agile mindset, adhering to lean budget and agile delivery with time box approach. Ensure what creates value gets prioritized and delivered first.
2. Apply systems thinking – Systems thinking and use of value stream mapping to understand dependencies, gaps and waste is important.
3. Assume variability; preserve options – SAFe prescribes maintaining multiple design options for long to ensure easier switch to new options during execution. This allows the organization to adapt the right path as it learns what will work best from the execution deliverables.
4. Build incrementally with fast, integrated learning cycles – It is important that the learning and adaption is done faster by the organization. The team must build with speed (timeboxing) and have faster learning loops and feedbacks to adapt and change on the move.
5. Base milestones on objective evaluation of working systems – The working systems results must be shared with stakeholders to evaluate if the objective is really met by the team.
6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths – Visualizing and limiting work in progress is Lean Kanban methods to check and limit how much work can be done at each stage and pay priority attention to the stages where work in piling up.
7. Apply cadence, synchronize with cross-domain planning – Applying a standard cadence and cross-domain synchronizing helps ensure progress is closely tracked and reported as well as dependencies and issues are identified and resolved with speed.
8. Unlock the intrinsic motivation of knowledge workers – Empower and motivate the team members to unlock their full potential and bring their best to work.
9. Decentralize decision-making – Part of empowerment is also to ensure decentralize decision making. Allow the team to make decisions for their areas while still maintaining some control. Step in only where leader has to make the decision.
10. Organize around value – All work must be done to ensure there is full focus on creatin value. Prioritize things that create more value and focus on delivering them first time right with speed and quality.
Organizations can apply and adapt to scaled agile framework (SAFe) in different stages,
1. Essential SAFe – Applied and used for individual projects and products management. Here is a quick overview of the same.
2. Large Solution SAFe – Applied and used for Programs management referred as large solutions. Here is a quick overview of the same.
3. Portfolio SAFe – Applied and used for entire Portfolio management consisting for programs and projects. Here is a quick overview of the same.
4. Full SAFe – Applied and used for managing entire organization (mission, vision, strategy) including portfolio, programs, products and projects management. Here is a quick overview of the same.
Kanban system was created by Taiichi Ohno from Toyota. The purpose was to have a card system for Just in time (JIT) lean manufacturing on the product floor. The idea originated to ensure short cycles of production based on actual demand with speed and accuracy.
It involved ensuring the factories spare parts (from suppliers) and finished goods (on the shop floor and warehouse) are just in time received and processed based on actual demand. This reduced the need for stocking of parts as well as finished goods by the manufacturing units. It also reduced all the resources costs to manage all the unwanted additional resources.
The Kanban system was made in such a way that at each stage of the production line the inventory is maintained as per the capacity limits. Any ups and downs are reported and addressed to ensure the end-to-end system remains smooth. The whole system worked based on bins and card system. The bin consisted of parts and the cards represented the number of parts requested at what time at which point etc.
Kanban prescribes a strict set of rules to be adhered to ensure it functioned well. The rules were as per below,
1. Every process must create request (Kanban) to its suppliers only when it has used all its existing supplies.
2. Quality and Sequence of incoming requests takes precedence and production is strictly followed based on incoming requests.
3. Without a formal request, no shipments and transports are allowed.
4. The items transported must have the request cards attached to ensure full transparency.
5. Quality is of utmost importance so no defective parts should be sent as they will impact the production and finished goods.
6. If there are pending requests above the threshold limit setup for the production line then those would need to be addressed on priority as they will impact production throughput.
Over the past decade the entire Kanban systems of cards and bins have been computerised by all manufacturing plants worldwide. In many ways the manufacturing Kanban systems are also integrated to enterprise resource planning systems (ERP). The computerised Kanban systems use messages, bar codes, scanners, emails and systems.
In the electronics Kanban system the bins interact with each other through the electronic cards specifying the parts, the inventory quantity, time slot and stage etc. There are two type of Kanban systems in the manufacturing plant,
Production Kanban: The production Kanban produces a fixed amount of parts or products as per the requests received and the parts are placed the requested bin consisting the Kanban request.
Transportation Kanban: The transportation Kanban as the names suggested related to the transportation of the requested parts. It is used to ensure full container loads are transported to the requested production workstations.
In the past 7 to 8 years the Kanban framework for Agile product, project, program and portfolio management has been introduced and is used by several organizations worldwide.
The Agile Kanban Framework works with visual dashboards consisting of Agile stages and progress update. Each stage also has a threshold which when crossed, requires attention and resolution to avoid it becoming a bottleneck. The steps can be defined as follows,
1. We can consider the visual board as a workflow consisting of electronics cards (look like post it notes).
2. The cards are actually user stories that need to be developed, tested and delivered.
3. The stages and stage names can be altered as per the product, project or program team needs.
4. Each stage (E.g. User Stories, To Do, In Progress, Testing and Done) has its own threshold based on the upper capacity of that stage resources. The stages can be also taken as columns in the swim lane of workflow (flow of work/cards).
5. The cards are moved from one stage to the next by the respective team member or owner of the Kanban board.
6. The board helps to visualize progress of various stories as well as track any bottlenecks requiring attention (e.g., in the Testing stage if there are more cards waiting then the Threshold, then it points the attention to resolve any issues faced to speed up testing)
7. Threshold is nothing but maximum amount of work the respective stage team can manage. So if a stage says 5, it means the maximum number of cards (user stories or tasks) the team can manage is 5 and anything beyond that would become a bottleneck.
8. If more than one stage crosses their maximum threshold then the work is stopped and all attention is given to the two stages to clear the bottleneck and backlog.
Here is a glance overview of Kanban principles and practices prescribed by Kanban university,
Kanban for Agile project management is more simpler than Scrum or any other Agile framework. This is because it works with a simple visual dashboard and requires no stipulated roles. The team decides how many stages and what roles they will need to operate the dashboard. Kanban is considered a continuous process and so it is not bound by project management principles. Instead it works on its principles of workflow with push and pull mechanism to move tasks across the board to completion.
This makes the Kanban approach effective but more relaxed and open ended while for agile there is timebox approach and speed are necessary. So to make Kanban based agile product, project and program management more effective and efficient, a hybrid approach is used by many organizations.
One such hybrid approach is called Scrumban which is mixture of Agile Scrum and Kanban Frameworks. The combination improves the efficiency of both the models. Scrumban consists of Scrum User stories, Sprint planning, Sprint reviews, along with Kanban principles of visual dashboard for progress tracking, push – pull mechanism to move tasks, work in progress threshold limits and just in time availability.
It also helps tighten the loose end on time using timebox approach. Scrumban removes all Scrum roles and follows Kanban principle of every one is considered to be at same level in the team.
Here is a quick overview showing comparison of Scrum, Kanban and Scrumban Frameworks.
In a similar manner, scaled agile framework (SAFE) has Kanban applied to its portfolio, program and project management stages to improve its efficiency, flexibility and visibility of progress across the enterprise.
Kanban agile project management can be electronically achieved with ease using solutions and application platforms like Jira, Trello, Monday and Kanban flow. Jira and Trello are the best platforms for online agile project management.
Kanban is widely recognised and started two to three decades back for Lean JIT (Just in time) Manufacturing. The adoption of Kanban for Agile project management is easier as many organizations already use it for their manufacturing sites. The Hybrid approach of combining Agile and Kanban Frameworks allows new opportunities for more flexibility and scalability in product, project and program deliveries.
Scrum is an agile project management framework that was developed for speedy software development in 90s. The Agile Scrum framework started being used from 2001. It became largely famous and almost every organization’s IT teams have started using it from 2011.
The framework is not just used for IT projects but it’s also used by business projects due to its ease of use, empowering methods, flexibility and speedy progress and delivery. There are many Agile Frameworks but the one largely used by all is Scrum. Here is the list of current famous five Agile frameworks used for project management, program management, Portfolio management and software development worldwide.
1. Scrum and Scrum @ Scale – Used for Projects, Program and Product Management.
2. Scaled Agile Framework (SAFe) – Used for Projects, Program, Product and Portfolio Management at Enterprise level.
3. Large Scale Scrum (LeSS) – Used for Large Scale Program Management at Enterprise level
4. Disciplined Agile (DA) – Used at Enterprise Level
5. Enterprise / Portfolio Kanban – Used for Projects, Program, Product and Portfolio Management at Enterprise level.
Let’s get back to Scrum. The Scrum term was introduced by Hirotaka Takeuchi and Ikujiro Nonaka for product development. In the millennium decade the Scrum Alliance was formed by Schwaber and team. This is when Scrum came to the corporate world for adoption and use for project management. As the years passed we moved in the information economy.
In the last decade adoption of Agile Scrum went up across the world but along the line also the need for how to scale it for the entire enterprise increased. This is when in last 7 years several agile frameworks emerged for adoption at enterprise level. Scrum remained in use for projects and programs while new agile frameworks like Scaled Agile Framework (SAFe) became more famous and adopted by many enterprises across the world.
Now let’s focus on understanding Scrum Framework and how it works,
The Scrum Framework is relatively easily formed and consists of roles (team), product features, meetings and deliverables. The entire project is done using small sprints to ensure focus, timeboxing and speedy delivery of features in every sprint. Let’s understand the scrum roles first then we can move into product features, meetings and deliverables.
Scrum Roles – Scrum consists of 3 roles. The product owner, scrum master and the team.
1. Product Owner – Product owner is the most important role of scrum team. The product owner as the name suggests owns the product, project or program. The product owner has the product, project or program vision. The product owner is also the sponsor. The product owner defines what is important and must be delivered first and what should be delivered in what order. The product owner supports the entire team in ensure they understand what deliverables and features are required. The product owner is generally the business owner or sponsor and sometimes the business owner’s delegate who understands the business needs clearly and able to decide and drive them.
2. Scrum Master – The scrum master is second most important role of the scrum team. The scrum master is normally one of the team members who is well respected and who can work well with all the team members. The primary job of the scrum master is to remove obstacles and impediments from team members work. The scrum master is also responsible to discuss daily progress and issues resolution.
3. Scrum Team – The scrum team consists of all the members of the team. This includes every role needed for the project and the respective sprint. The scrum team members are empowered to choose the features and stories they want to work on in the project. The scrum team updates their daily progress and issues and impediments in the scrum meeting.
Agile Product Artefacts – The scrum framework doesn’t work with any large documentation and knowing every detail of the product upfront. This is what makes it easier and flexible to start and change as the team progresses. Here is a quick overview of the Product Artefacts Model,
Product Vision – The product artefacts start with the product, project or program vision. The vision is what the product, project or program will achieve in 1 or two simple sentences.
Themes –The vision leads to Themes, the themes are major modules of the product, program or project. The themes are broken down to Epics.
Epics – The epics are sub modules of the product, program or the project. The Epics are then broken down to product features.
Features / User Stories – The product features are then either broken down or converted to one or more user stories. User stories clearly articulate what input, action and result is expected from each user story and how it will help the user.
Tasks – The user stories are broken down to tasks. The scrum team members generally work on the user story level and they execute the tasks to deliver the working user story. Here is a brief model overview and its illustration.
Due to space limitations you will only short text is used in the illustration. In general all user stories have to be written in the format of “As a user [persona], I [want to], [so that]”. E.g. The User Registration feature can be written as “A an online user I want to be able to register online so that I can login and register for online learning courses”.
Similarly the tasks can be detailed out to specific actions needed to achieve the user story readiness. They might not be specified just as Develop, Test and Deploy.
The user stories are prepared by the product owner. Once the product features and user stories are ready, the team ready to the estimation for them.
Agile Scrum Process – Let’s understand the way of working and how the project management is done using scrum,
Product Backlog – All the user stories along with Themes, Epics and Features are put up in a product backlog by the product owner. The Product Backlog is list of all the features that must be made ready for achieving the product vision.
User Story Estimation – User stories are reviewed and estimated by the entire team. The Scrum Master arranges the estimation meeting along with the product owner and all the scrum team members. The estimation is done using a point system (1, 3, 5, 7 etc.) or size system (small, medium, large and extra large etc.).
The scrum master and the team first decides how much weightage each point of size has in terms of number of hours of work. This is done using teams past experience and improved as the team moves forward with sprint executions. The weightage helps the team decide how much time each user story will take to get it ready. Based on the combined size of all stories under one epic, the epic’s size is determined and same applies to themes.
The estimation is done using consensus model where for each user story the scrum master asks each member to score the points the scoring is then discussed and a consensus is reached to finalize and assign the points or size to the story. The cycle continues until all stories are assigned with points and size.
Sprint and Sprint Planning – As the user stories are ready and prioritized product backlog is fully in place, the team can begin with sprint planning. A sprint is cycle of 2 to 4 weeks in which the team picks up the stories from the product backlog in the order of priority and puts them in the sprint specifying in which sprint what stories will be made ready.
Each sprint then gets its own sprint backlog consisting of user stories to be delivered. Each sprint must ensure that a fully working user story is delivered at the end of the sprint. The sprint deliverable must be fully working and demo able to the product owner. The product owner must signoff and accept the features delivered to mark that user story complete.
The team works out the entire sprint planning to ensure they know how to execute, how many sprints (equals to how many weeks and months) and how much resources will be required to get there.
The deliverable from each sprint is referred as increment and at the end of all sprints, all the must have user stories should have been delivered for the product vision to be marked as achieved.
The Agile approach is a timebox approach to ensure the team reaches its product vision with speed and agility. The emphasis is on delivering results and not so much on detailed documentation, long workshops and long meetings. The focus is on working in small size teams in each sprint to deliver results.
During the sprint 1 to 6 team members can work together to pick up their respective stories. The scrum team members working on the user story, define and execute tasks for the readiness of respective stories.
Daily Scrum Meeting – On a daily basis at a fix time the entire scrum team meets up to share progress made, progress planned, issues and impediments. The scrum master arranges the meeting and ensures all scrum team members join in including product owner. The product owner might not join every day but based on the needs can be pulled in for discussion and guidance.
The meeting is called “Daily Scrum” and its only 15 to 30 minutes max. It is also called as a stand-up meeting, means the team only focuses on sharing what’s important and where they need help. Based on the updates shared, the scrum master reaches out to respective team members separately to understand their issues / impediments and help them resolve it with priority.
The Daily scrum meeting ensures that the scrum team doesn’t lose motivation and they are able to time box and move with speed to deliver.
Increment – At the end of each sprint a working set of user stories are demoed to the product owner to seek the acceptance for completion. The combine set of users stories in the sprint are referred as “Increment” as they make only part of the product vision. Eventually when all sprints are completed, all increments combined make the product vision come through.
Sprint Review – At the end of each sprint, the scrum team come together to review how the sprint execution and deliverables faired against the plan. It is possible that some user stories took longer impacting some other stories that couldn’t be completed. It is also possible that some user stories couldn’t be done due to dependency and / or impediments from other user stories. The incomplete users stories are then prioritised and moved back to the product backlog to be taken up in the next sprints.
Burn-down Charts – The burn-down charts acts as a daily weather forecast report for the team to see how they are progressing jointly against the plan they have agreed.
The scrum master and the scrum team also maintain a burn-down chart that shows them their planned progress and how they are actually progressing for each day. In the burn-down chart it is possible that there are some peaks and valleys seen as the execution of sprint and efforts spent might not be exactly same all across.
The scrum master and the team together strives to make sure they keep their commitments, help each other and achieve the needed results.
Sprint Retrospective – The scrum retrospective meeting is also held at the end of each sprint after the sprint review meeting. The purpose of the scrum retrospective is to focus on individuals, collaboration process, tools and definitions of done (deliverable as per acceptance criteria). The team discusses how things went, what worked well, what needs to improve. The improvements are then taken up by the scrum master and team members to improve and feed in for the next sprints to improve collaborations process, tools and deliverables.
The team then moves on with next sprint and any incomplete sprint backlog from previous sprint is also taken up in the next sprint or sprint after next depending on team’s decision. The execution cycle continues in the same manner for each sprint.
Agile Scrum Framework works very well because of its focus on results, empowerment for team members, no detailed documentation cycles, flexibility to adapt and change as we move sprint by sprint and most importantly, breaking down the product into smaller increments that work and allow the product owner to see results in short cycles (sprints) of 2-3 weeks, without waiting for months.
Agile Scrum Framework is used across the world by thousands for organizations to team up and deliver great results. Many Organizations have even moved further with scaling up the agile way of working by using the enterprise agile models of scrum and other frameworks. Some organizations have also gone ahead with a hybrid model mixing Agile, Waterfall and Lean, Kanban frameworks to fit their needs.
A Theme is a key objective or goal which could be across projects and products. Themes can be broken down into sub-themes, which are more likely to be product-specific. At its most granular form, a Theme may be an Epic.
Themes can be used at both Programme and Project Level to drive strategic alignment and communicate a clear objective or goal.
EPICS
An Epic is a grouping of User Stories that can be logically grouped. Epics are broken down into user stories to detail them out.
Epics can be used at a both Programme and Project Level.
User Stories
An User story is an Independent, Small, Testable requirement that has clear acceptance criteria and estimate.
User Stories are great for Project and Product Development Teams as they are easy to understand, discuss and prioritise – they are prioritised in a product backlog and become part of Sprint as deliverables.
Tasks
The project / product team members break up the User Stories into smaller Tasks during the Sprint Planning Process to achieve the user story functionality. User stories that are too small may not have a need to break up in tasks.
The world markets and business changes are getting more and more dynamic every day. This leads to continuous business change and expectation to have change deployed in the shortest and fastest time frame possible with required agility and flexibility of business processes.
Given the speed of change and the part Information and Communication Technology is playing we have seen the need for how IT system changes are dealt with and executed. Business is constantly asking IT to make the IT system changes faster and faster while still ensuring quality, cost and time needs are efficiently managed.
A major part of IT system change execution is related to how its programs and projects are executed. The traditional project management methodologies and IT projects water fall method of executing and delivering project outcomes are not helping. The key reasons for water fall approach not working are,
Business changes are dynamic and time to get the change done is shorter means even business doesn’t have the complete idea of every details of the product. Hence requiring faster iteration of part of the product benefits to build on the next set of requirements.
The waterfall method of executing IT projects lead to long project execution cycle that relies on 100% clear business change requirements and detailed product requirements. This requires longer time to get things documented, designed, built and then longer testing, fixing and deployment times.
With traditional waterfall project execution there is lost opportunity for improving the product as the business gets to see the product only at certain stage of the project by when there is not much room for changes given the need for speed.
In traditional waterfall projects the business is unable to make interim decisions stopping the project or changing its path at any stage of the project for better product creation by saving time and cost spending.
The above reasons lead to the need of a new IT projects/programs execution methodology. In 1990s a new methodology emerged called SCRUM which gives the required agility in any IT product delivery. The methodology was more tried and used in early 2000 and last decade by big software development vendors that continuously work on software product development and releases.
SCRUM focuses on products delivery by delivering its prioritised features in smaller (2 to 4 weeks) iterative cycles known as sprint. Each sprint delivers a set of working product features to the product owner for testing and releasing it to production. The whole agile development cycle continues as iterative sprints until the entire product with all its features are delivered to the product owner.
As each sprint (iteration) is of maximum 4 weeks, the product owner at the end of each sprint has authority to approve the next sprint or cancel and stop further product development. The product owner also has authority to change product priorities and add or remove features to the product and hence allowing the agility and flexibility of product development.
There are other positive points of SCRUM (Agile) way of product development. The sprint is delivered by a team working on that sprint. The team has required skilled resources that choose the activities themselves and create a complete sprint plan. The team appoints one of the team members as SCRUM Master who ensures that every single day the team members update each other and SCRUM Master help to remove any roadblocks for a successful produce delivery. The entire team is responsible for product delivery and if a sprint is successful then it’s due to the entire team and when it fails the team notes down the downsides and work on improving it in next sprint.
All in all SCRUM (Agile) way of doing IT projects can be successfully used for all the projects/programs that are planned to deliver products. It’s said that by 2015 at least 80% of IT projects would be using SCRUM (Agile) way of doing projects. So the earlier we start using the better. Even if 70% of IT projects are done in SCRUM (Agile) way then it would do wonders for business change projects.
More then ever the businesses are getting automated and enabled using IT solutions. Every part of the organisation are dependent on one of more IT solutions, some in house and some bought from the market. The IT solutions are made with the need for enabling the business and often leaving the useful ones rest are forgotten and left as legacy/archives to be referred only when needed.
With fast changing business needs applications are created, used and left even faster then we all could think about. Day in and day out business creates document libraries, project team rooms, intranets and a lot more. Over years this turns out to be a huge mess and close to unmanageable. The result is higher maintenance and infrastructure costs. Legacy / archive appls, as they are hardly used result in Loss of knowledge.
In the era of acquisitions and disentanglements to speed up innovation and change business directions, its even more essential to ensure companies have defined and controlled solution catalogue which is well managed and serviced.
For MNCs this is extremely essential as MNCs have multiple office locations, the applications appear like mushrooms in those locations and then grow into a huge architectural and landscape mess to manage and maintain. The issue starts with slight differences in global and local process and document needs. Ones allowed localize the changes continue one after another leading into a fully customized monster application and that too not just in one location but many. The result is enormous costs to maintain, control and change business applications and processes.
Application convergence can be addressed by addressing the following in order mentioned,
Bottom Up Dos
Ensure the As is application portfolio is clearly documented with ownership from IT and business
Collect relevant solution changes and yearly maintenance costs to ensure full visibility
Get the collected data well categorized by business process, functions, platforms, location etc.
Create some data analysis and reports showing number of applications in different dimensions of the categories to be able to see the duplicates, expenditure and other information useful to make decisions.
Ensure the 1st hand bottom up approach analysis and output is shared with the top management and local businesses alike in condensed and relevant manner.
Identify the champions that helped in bottom up approach and they should be used for the application convergence activities going forwards.
Identify the road blockers and how they can be kept in control or convinced that application convergence is good for the whole organisation
Ensure during the whole process that current business and activities are not affected as they will create –ve publicity and barriers for progress
Top Down Dos
At the company level define the Application convergence initiative ensuring full business buy in and management support throughout the organisation
Start with the Business process layer to define the core business processes. Ensure core functions, business processes are well documented and have clear global ownership.
Short list and select the required architecture and portfolio management tooling as these would be needed for ongoing use, structure, control and management.
Business process by business process start harmonizing the processes and select the best solutions from existing ones or new ones (from the market or built in house)
Focus on quick wins by choosing the valuable but easy transitioned business processes and start filling up the solution catalogue with global solutions. This also means start closing down by transitioning old solution towards new ones and launching them as one global solution
Focus on clean ups that can aid to reduce the infrastructure and maintenance costs and hence result in better use of resources across organization
All new business demands should fit in to new way of working with only one solution at company level.
Another important point to keep in mind is Application convergence in MNCs could take from up to 1 to 5 years although a lot will be achieved in 2 years while the complex applications convergence would require a lot of time and efforts and proper strategic planning to make it happen with business change.
If the above is done in write order with proper management support and control then it ideally should lead to globalised solutions which if made with agile and service oriented architecture would result in agility to cope with business process and tools changes done fast enough and efficiently across the organisation. On the other hand running application convergence will lead to whole IT landscape clean up and steam lining ideally resulting in savings.
We are in a decade where changes of all types and shapes appear from various angles. We all are demanded to adapt as well as deliver successfully on all our activities and task to eventually ensuring the business change request delivered. In the years to come we will continue to face more and more changes and with all these changes comes, risks and delays if not handled promptly and properly.
Amongst all these changes and need to faster, the word Agile and Nimble are heard very often these days. Being Agile and Nimble is all about being lean but at the same time able to handle and adapt to change, growth and even discarding the change when necessary.
For the business change/growth the competitive advantage and window opportunity to be ahead of the competition is getting smaller and smaller. This means if we are delayed for the window then somebody else will take the opportunity and this will result in loss of market share and business growth. This is the key driver for the need of speed in doing so its also key to be able to change path and decide on different routes of changes as they come.
The traditional way of managing changing over years is becoming obsolete given the Gen-X, Gen-Y and later in the decade Millennial coming work. The use of internet for real time collaboration, communication and ideas build up as well as taking advantage and launching new growth options is becoming the name of the game.
The unpredictability of whether, natural disasters and economical changes are putting all business on their toes to react to changes even more faster and to deal with them effectively. Failure to do so have shown business going bankrupt or being taken over by others with in no time.
Even Mergers, Acquisitions and Disentanglements are taking speed where these are more and more asked for be dealt with fully in 3 to 9 months.
All of the above asks us to find out methods and possible ways to handle changes differently then we are use to.
Going towards Agile way of doing things allows us to bring more ownership of actions towards the group of people who need to do it as well as ensure that every sprint the team improves as well as delivers part of the business change requested. Agile is sure shot way of ensuring we are more adaptable to changing routes/options of business, while its not a one size fits all method. This means it needs to be applied and used selectively as it does require efforts and time for an organisation to get used to it and to keep doing it the right way.
In today’s fast paced world with series of parallel changes demanding speed and agility to get things done as a team and individuals. Its essential to develop techniques that allow us to better collaborate with less time and more productivity.
In this article let’s focus on how we can make our progress tracking more effective by doing it in a simple yet effective manner every day/every week. This is also called as Stand Up Meetings. The name stand up is to ensure that people know it’s a short meeting and they need be upto the point, specific and relevant to the group they are talking to.
This has been a very effective method of running progress checks as well as “depending on each other” to keep making the progress we intend to achieve our targets.
The meeting should be arranged everyday/every week at a specific time. As a stand up meeting the overall meeting should be of 15-20 minutes at max. Here is the Agenda of the meeting and Do’s/Don’ts..
Agenda
Each individual member of the meeting has to focus on talking only about following,
What have you done yesterday/last week
What will you be working on today/this week
What roadblocks/issues you see affecting your progress
Do’s and Don’ts
The chair person of the meeting should not be the hierarchical authority. It should be one of the project team member with whom people are very comfortable working
The meeting team should comprise of 2-4 people to be more effective and brief
Every member must prepare what needs to shared and it has to be at max 3 to 5 minutes per person. This also means share things that are relevant for the group and be specific.
The chair person/delegate should record the minutes specially the problems/issues and pass it to the appropriate action driver to ensure those actions are acted on with priority
Focus on ensuring that this does not become a blame meetings(pin pointing) and Ensure it does not move towards highly operations/technical details discussion
Benefits
You will see that all will get use to a very effective and upto point meetings
If done every day there will be only few actions to note and work on
Communication would be crystal clear amongst the team
Team work (depend on each other) will become much more stronger ensuring high level of collaboration
Being short and effective meeting would lead to member’s eagerness to join the meeting
Go ahead and use it. I am sure you will find it very effective too.
Learn-Share-Change-Grow 