The Required ‘Cultural Transition’ For Agile-Scrum Teams
By Rumesh Wijetunge
"It is not the strongest of the species that survives, nor the most intelligent. But it is the one who is most adaptable to change" - Charles DarwinTechnology today is evolving rapidly at an exponential rate. Business entities in order to survive and thrive must adopt and adapt to technological advancements at a rapid rate. The dwindling profit margins, the shrinking in time to market, globalization, and the technological advancement of competitors mandate organizations to innovate put out their products and services as soon as possible.Software project management has evolved rapidly over the last few years. Organizations large and small alike are rapidly transitioning into using Agile software development and engineering frameworks resulting in technology advancement at an exponentially rapid pace. The struggle of adopting and adapting to Agile delivery for organizations and teams alike is well understood and documented. The culture of the organization and the team plays an important role to facilitate this agile adoption.The effects of globalization and technology have a direct impact on the Software Development Industry as well. Software project management too has evolved rapidly over the last few years to cater to this change. Organizations large and small alike are transitioning into using change-driven software development and engineering frameworks rather than sticking with plan-driven software project management approaches.However, the struggle of adapting to Agile practices is a universal problem and this may the case for years to come. An area of difficulty in terms of this adaptation to agility is organization and team culture. Today, through this article we will look at the culture of traditional plan-driven software development organizations and then the requirement of culture for change-driven Agile Software Development organizations.Culture as an enablerCulture is often defined as ‘the way things work around here’. Schein (1980) defines culture as the pattern of basic assumptions that a group learns, or which is taught to new members as the correct way to perceive, feel and think in relation to situations they encounter. Many organizations do similar activities, but no two organizations do activities or tasks in the exact same way as the other, and no two organizations feel the same.Transformation into an Agile team should first happen at an organization level that they can be cascaded down to the team level. It is the senior leadership’s responsibility (owners and CXO’s) to embrace agility, and then to create the corporate values, beliefs, behaviors, and practices necessary to activate this culture. Scrum masters as the Agile leadership of the organization must understand this corporate culture and then adapt the same to teams as necessary. Schein defines the culture at 3 levels.Level 1: Artifacts or the visible features, which reflects the culture (roles and people, symbols, narratives, activities etc.)Level 2: Beliefs and values which the organization and the scrum team (leadership, integrity, trust, etc.)Level 3: The deepest and most important level which consists of assumptions which shape level 2 and level 1 elements listed above.The Agile leadership is responsible for creating and communicating cultural elements at all 3 levels to team members so that they understand, embrace and develop the Agile culture.The transition in Agile cultureBelow is a depiction of 4 basic types of culture as defined by Handy (1999).Traditionally software development organizations followed plan-driven SDLC approaches to develop and deliver solutions. The Power and Role cultures were evidently visible in these sort organizations. The power in terms of initiating a project, deciding on the resource requirements, deciding on the budget and deciding on the scope was with a few key individuals within the organization. Role of the customer account manager, project manager and the other project roles such as developer, business analyst, QA engineer was clearly defined. If any information was required or if a client demonstration was to be carried out the team had to wait for a considerable period of time to communicate, take necessary approvals and to implement the same. These organizations and teams inherently had the problems of role conflicts, contradicting priorities, miscommunication and slow decision making which ultimately resulted in delayed low-quality projects.The task and person cultures are more suitable for Scrum projects. Yes, the scrum master, product owner, and implementation team roles and the communication lines defined properly for an Agile project to run smoothly. But the team must be self-organizing to identify tasks to perform in order to create and deliver value to the relevant stakeholders. Each team member must be a cross-functional team player capable of fitting into any role and perform any task as required to deliver the solution. The scrum master must facilitate discussion within and across multiple teams and stakeholders as deemed fit to remove impediments and move the project forward. Team and individual success must be celebrated along with the achievement of common project objectives.For more information on types of culture please watch the video through below link.ConclusionAgile requires a paradigm shift, which is more specifically a shift in the culture of management to leadership. This must come from the top down and be embedded in corporate strategy. Harmonious dissemination of this information to all relevant stakeholders both internal and external will ensure the success of Agile projects.
Rated 4.5/5
based on 2 customer reviews
The Required ‘Cultural Transition’ For Agile-Scrum Teams
By Rumesh Wijetunge
"It is not the strongest of the species that survives, nor the most intelligent. But it is the one who is most adaptable to change" - Charles DarwinTechnology today is evolving rapidly at an exponential rate. Business entities in order to survive and thrive must adopt and adapt to technological advancements at a rapid rate. The dwindling profit margins, the shrinking in time to market, globalization, and the technological advancement of competitors mandate organizations to innovate put out their products and services as soon as possible.Software project management has evolved rapidly over the last few years. Organizations large and small alike are rapidly transitioning into using Agile software development and engineering frameworks resulting in technology advancement at an exponentially rapid pace. The struggle of adopting and adapting to Agile delivery for organizations and teams alike is well understood and documented. The culture of the organization and the team plays an important role to facilitate this agile adoption.The effects of globalization and technology have a direct impact on the Software Development Industry as well. Software project management too has evolved rapidly over the last few years to cater to this change. Organizations large and small alike are transitioning into using change-driven software development and engineering frameworks rather than sticking with plan-driven software project management approaches.However, the struggle of adapting to Agile practices is a universal problem and this may the case for years to come. An area of difficulty in terms of this adaptation to agility is organization and team culture. Today, through this article we will look at the culture of traditional plan-driven software development organizations and then the requirement of culture for change-driven Agile Software Development organizations.Culture as an enablerCulture is often defined as ‘the way things work around here’. Schein (1980) defines culture as the pattern of basic assumptions that a group learns, or which is taught to new members as the correct way to perceive, feel and think in relation to situations they encounter. Many organizations do similar activities, but no two organizations do activities or tasks in the exact same way as the other, and no two organizations feel the same.Transformation into an Agile team should first happen at an organization level that they can be cascaded down to the team level. It is the senior leadership’s responsibility (owners and CXO’s) to embrace agility, and then to create the corporate values, beliefs, behaviors, and practices necessary to activate this culture. Scrum masters as the Agile leadership of the organization must understand this corporate culture and then adapt the same to teams as necessary. Schein defines the culture at 3 levels.Level 1: Artifacts or the visible features, which reflects the culture (roles and people, symbols, narratives, activities etc.)Level 2: Beliefs and values which the organization and the scrum team (leadership, integrity, trust, etc.)Level 3: The deepest and most important level which consists of assumptions which shape level 2 and level 1 elements listed above.The Agile leadership is responsible for creating and communicating cultural elements at all 3 levels to team members so that they understand, embrace and develop the Agile culture.The transition in Agile cultureBelow is a depiction of 4 basic types of culture as defined by Handy (1999).Traditionally software development organizations followed plan-driven SDLC approaches to develop and deliver solutions. The Power and Role cultures were evidently visible in these sort organizations. The power in terms of initiating a project, deciding on the resource requirements, deciding on the budget and deciding on the scope was with a few key individuals within the organization. Role of the customer account manager, project manager and the other project roles such as developer, business analyst, QA engineer was clearly defined. If any information was required or if a client demonstration was to be carried out the team had to wait for a considerable period of time to communicate, take necessary approvals and to implement the same. These organizations and teams inherently had the problems of role conflicts, contradicting priorities, miscommunication and slow decision making which ultimately resulted in delayed low-quality projects.The task and person cultures are more suitable for Scrum projects. Yes, the scrum master, product owner, and implementation team roles and the communication lines defined properly for an Agile project to run smoothly. But the team must be self-organizing to identify tasks to perform in order to create and deliver value to the relevant stakeholders. Each team member must be a cross-functional team player capable of fitting into any role and perform any task as required to deliver the solution. The scrum master must facilitate discussion within and across multiple teams and stakeholders as deemed fit to remove impediments and move the project forward. Team and individual success must be celebrated along with the achievement of common project objectives.For more information on types of culture please watch the video through below link.ConclusionAgile requires a paradigm shift, which is more specifically a shift in the culture of management to leadership. This must come from the top down and be embedded in corporate strategy. Harmonious dissemination of this information to all relevant stakeholders both internal and external will ensure the success of Agile projects.
Rated 4.5/5
based on 2 customer reviews
171
- by Rumesh Wijetunge
- 18 Sep 2018
- 4 mins read
"It is not the strongest of the species that survi... Read More
5 Hurdles that Scrum Masters Commonly Face
By Ridhi Chhabra
Agile has gained a significant track and has been adopted by all organizations. Agile Methodology today has become one of the most popular and most dynamic project management styles among the software development teams. And Agile is also being adopted by various other functions. It is important to note that Agile can be applied to many types of teams and projects and should not be thought of as limited to engineers or software development projects only.We run all our software delivery through an Agile methodology called Scrum. Scrum is well-recognized amongst engineering teams, but a variety of teams across industries have come to love the Scrum way. From manufacturing to operations and education, businesses of all kinds have used Scrum practices and successfully. As long as your projects involve a concrete product, Scrum can work for you. We have been using Scrum for last few years and have some great success with it. But, still the Team come across various common Scrum Pitfalls.Many organizations are adopting Agile and Scrum for producing higher quality products and services.As per the statistics are given by PwC, “Agile projects are 28% more successful than traditional projects.”Almost three-quarters (71%) of organizations report using Agile approaches sometimes, often, or always. (source: capterra)So why not,Organizations are hiring Scrum Masters for implementing Scrum Framework. It’s a sole responsibility of a Scrum Master to make sure it’s fully implemented and followed by the team in an organization.Scrum is easy to understand but hard to implementWho is a Scrum Master?The Scrum Master is a champion for a Scrum team. He coaches the team, the product owner, and the business. The Scrum Master is a multitasker were deeply understands the work being done by the team, motivates the team and makes sure that the teams are following the Scrum processes and will also work together with them to continuously improve them.How important is a Scrum Master?Scrum Master also ranks on the top of the hierarchy on most of the Agile or Scrum Process, with an eye towards a better understanding of role and importance, here is a closer look at the Scrum Master roles. 1. Scrum Master plays a vital role in the success of the project, he serves as a glue that can hold the entire project.2. Scrum Master may not participate in daily Scrum meetings but supports the entire team.3. Scrum Master helps in strengthening the Agile development team4. Scrum Master facilitates team meetings, which also includes Daily Stand-up5. Scrum Master aims to deliver the maximum value to the customer.Let’s have a look at the 5 hurdles that Scrum Master commonly face:1. Managing Role ExpectationsMany organizations, as well as the upper management, confuses the role of the Scrum Master with a Project Manager. However, the most important thing that we all should know is that the Scrum Master is a Scrum facilitator for a team as well as an organization.However, sometimes management expectations are different, which makes the life of a Scrum Master little harder. We all need to understand that Scrum Master is a facilitator, a guide, a process follower and most importantly, a Servant Leader.2. Change ResistanceAs per Mike Cohn, it is the social aspect of change that can create resistance, all resistance comes from specific individuals. Teams or departments do not resist changing to Scrum, Individuals do.So, when we talk about Scrum implementations, the Scrum Master is the change agent for the same. It’s a major hurdle faced by a Scrum Master during the implementation. Change Resistance is not a surprise, it’s the most expected reaction whenever a new change is introduced. Tip: Choose a length of the Sprints in such a way that it can resist change.There are many ways for adopting Scrum patterns and overcoming change resistance. You will get that Scrum adopting patterns in my previous article- Patterns For Adopting & Spreading Scrum In Organizations.3. Keeping everything Time-Boxed When we talk about implementing Sprints, every event is supposed to be time-boxed in order to get productive results. For example, the Daily Scrum event should not exceed 15 minutes, but in reality, we see team members start discussing their technical difficulties and the meeting goes longer than the allotted time. It’s one of the most common challenges for any Scrum Master.Well, a funny thing to try to overcome this hurdle is to make the team members stand for 15 minutes. Hide all the chairs! They will eventually get tired and finish up the meeting.4. Handling Urgent Change RequestsScrum Masters follow the rule when implementing Scrum which is to never accept changes within the Sprint. We can handle the change requests at the end of the sprint or at the start of the Sprint but not in between. However, in a practical world, we see Product Owners/Customers/Stakeholders coming up with an urgent change requests or bugs.However, it’s also not good to blindly follow the process without understanding the business and market aspects. It’s always better to communicate, collaborate with all the Stakeholders, replan and then make good decisions.5. Distributed TeamsIt is one of the most common barriers faced by a Scrum Master. When the teams are distributed geographically, there are sometimes delays, network issues, cultural or regional issues, different Time Zones, different working hours, it is always difficult to get everyone connected and collaborate/communicate with everyone.Thanks to all the technologies, applications out there that help us overcome this hurdle whether it’s communication, video conferencing, there are many tools available.Scrum Master also come across the following challenges:1. Scrum Master acts as an admin:Basically, Scrum Master tasks start with booking meetings, scheduling events, taking notes, and inviting people to ceremonies. All these may be the primary function of the Scrum Master and these deals with making the team be effective. The tasks involve various challenges.2. Lack of Agile training for the teams:As the Scrum Master is meant for the team, it’s a responsibility to make sure all your team members have foundational Agile training. This is one of the most problem faced by Scrum Master.To summarize, I would say, these are the just the “Hurdles” commonly faced by Scrum Masters but not the “Blockages”. These obstacles can be jumped over, with good skills, expertise and, experience in Scrum implementations. Keep Learning!
Rated 4.0/5
based on 2 customer reviews
150
- by Ridhi Chhabra
- 18 Sep 2018
- 4 mins read
Agile has gained a significant track and has been ... Read More
Decision About Which Agile Method To Use - A Perspective
By Raju Dhole
Introduction:Agile methods have gained widespread acceptance in software development organizations for formulation and development of solutions for enhancing existing products or creating new ones. The method has been very effective in the continuous delivery of new and effective solutions.Organizations trying to introduce Agile methodologies, in the beginning, are faced with a choice of which type of Agile methodology is best suited for their environment and types of project work. You may learn more about the challenges encountered by the first-time Agile organizations here.The Agile Manifesto favors the delivery of working software in comparison to comprehensive documentation. There is a constant emphasis on a relation between organization and developers rooted in-Trust,Integrity, andTransparency.It may not be a huge shift, but is still a powerful challenge for many companies. The team should be trained well, should be aware of Agile concepts and should have the required tools needed to perform. A team of experienced and skilled developers is more efficient to take decisions when compared to a less experienced team and understands customer commitment much better. Agile delivery values direct interaction and business user collaboration instead of uneven communication in the life cycle at fixed points. Effective involvement of the business reduces the delivered features risk that do not meet customer requirements.How to decide the best Agile methodology that is suitable for an organization?Despite the fact that every Agile methodology offers incremental and iterative delivery of software, the differences lie in the way artifacts produced and each methodology is executed.Let us discuss in detail the most popular Agile Methodologies:Scrum: Scrum is focused on self-organizing teams. Its core principles are aligned with client-driven adaptive planning. Scrum method’s main priority is the delivery of working software in no more than 30 days. Delivered software needs to be in releasable shape.Minimum documentation is supported. Scrum is most used in the Agile framework. Its widespread usage and benefits have made it the most popular Agile method.Extreme Programming(XP): It keeps things simple and concentrates on the continuous implementation of best practices such as-Ongoing testingRefactoringCode reviews (pair programming)Continuous integration.In this method, there is a focus on the developer’s capability and getting into the development of the working prototype as fast as possible.Feature Driven Development (FDD): Breaks down the delivery of a larger product into small features. Typically, FDD is characterised by-Short iteration cyclesSimple processesSuitability for predictable evolutionThe method needs experienced resources to define the required features in great details to make them implementable.Kanban: It is based on Toyota’s just-in-time (JIT) production system. The salient features are as follows-Focuses on eliminating bottlenecksIncredibly simple and powerful Kanban boardsKanban uses Flow and visual methods to bring elements of agile in the overall development process.Makes elaborate use of visual tools.Typical usage involves a space in the office area with printed boards showing status of the activities as shown in the diagram below.Lean Development: Lean Development concentrates on offering value for money. It recommends amplifying learning, avoiding unnecessary errors, delivering as early as possible and deciding as late as possible. The first and foremost principle of lean project management is diminishing waste in an established process. It is more frequently applied to production and manufacturing than in product development. Lean mainly focuses on key process improvement points, such as standardizing means of production and reducing bottlenecks. Although Lean has a different application than the Agile methodology, there are certain common elements such as-Valuing a strong facilitator andPipeliningDSDM: It is developed from a business perspective and lays a strong emphasis on project management. The plans produce based on increments.Sometimes, a combination of multiple methods is the best solution. For example, a combination of Scrum and Kanban is a preferred combination for projects that need the iterative approach of Scrum and the visual elements of Kanban. Similarly, pair programming aspects of Extreme programming (XP) are borrowed for Scrum development teams. It is also advisable that, Agile is not a suitable methodology for some projects. This also should be kept in mind while evaluating an appropriate Agile methodology.In Summary:Agile method to be used for an organization depends on the objectives and desired outcomes. The methods can be implemented either in an existing program or for a new one. Current state and resources available will be of prime importance in deciding the approach and the timeline of implementation. It has been proven time and again that Agile methodologies help an organization to improve the speed of product delivery and quality. They also help establish clear communication channels within the organization and with critical customers and have an approach and method to incorporate customer feedback quickly in the product roadmap.
Rated 4.0/5
based on 0 customer reviews
192
- by Raju Dhole
- 12 Sep 2018
- 3 mins read
Introduction:Agile methods have gained widespread ... Read More
Deliver High Business Value With Agile Opportunity Canvas
By sayee krishna
I would like to start this blog with a question. Business case, quite commonly used term in Project Management. Do we agree?It is a document explaining the justification for a project and expected outcome. Let us have a look at Project, Program and Portfolio Management in the image below.Every single initiative or project within an Organization is aligned to Organizational strategy.In an Enterprise level, we tend to see a lot of ideas and requests emerging from stakeholders, clients, internal teams, outcomes of market research. These ideas and requests will convert into a Project, if we see a potential opportunity. In traditional approach or Agile approach, every idea or request should be validated to ensure the right investment is made. Agile is a widely used terminology in IT industry. People often stumble upon understanding Agile and Lean. Lean Methodologies focuses more on value, elimination of waste and delivering the product in small batches. Agile is a subset of Lean thinking. Agile movement was formed in 2001, Outcome of which is Agile Manifesto and 12 Principles for Agile Software development. Agile is an umbrella term covering different methods and frameworks such as Scrum, Scrumban, XP, FDD etc. All Agile approaches/frameworks emphasizes more on Agile Manifesto and 12 Principles.Agile Model:Demand Management in Traditional Approach/Waterfall model: In the traditional approach, a project is selected over another project through Project evaluation tools such as Cost-Benefit analysis, Decision Matrix etc. A project charter will be created during the initiation phase of the project which captures business case, high-level requirements, timeline/milestone, risks, costs and other constraints. A detailed scope in the form of "Statement of Work" is approved during the planning phase. Planning is one time in a Waterfall model and will take a considerable amount of time in the project. Scope(Feature) is Fixed, Time and Cost is flexible in Traditional approach. Any changes to the scope will be difficult to handle in Waterfall model. There are a lot of risks involved in Traditional approach, as planning is one time. Fig: Iron triangle- Traditional Approach Demand Management in Agile Approach: In the Agile approach, planning is continuous. Planning is done at different stages. This reduces risks.Strategic PlanningPortfolio PlanningProduct PlanningRelease Planning – Quarterly by entire teamIteration Planning – Bi-Weekly by entire teamDaily Planning – Daily by entire teamFrequency and required participants for Strategic, Portfolio and Product planning will differ across organizations. Fig: Agile Estimating and Planning In the Agile approach, Feature remains flexible, Time and cost are fixed. Agile approach is incremental and iterative in nature. In the Agile approach, we do not have a detailed scope slated during the start of the project. As we evolve during the development phase, there might be new features or enhancements identified by the customers. Fig: Iron triangle- Agile Approach In Agile Demand Management Cycle, an idea/requirement/enhancement is chartered in an Opportunity Canvas which gets reviewed by Investment cabinet. As per agile manifesto # 3- Customer collaboration over contract negotiation and Agile Principle # 1: Satisfying the customer is of highest priority: "Agile opportunity canvas" creates more visibility to the customer and the product owner to prioritize new requirements or enhancements over others. (Enhancements which needs a development effort of minimum 2 months would be considered to be chartered in an Agile opportunity canvas). Demand Management process is followed in both Traditional and Agile approaches. In Traditional approach, since the scope is clear it will be a one-time activity. But in Agile, as we do Rolling wave planning on shorter time span to deliver customer value, we would need a robust demand management process to ensure the right requirements were approved and investment is made for right product or feature. Fig: Opportunity Canvas & Demand Management Agile Opportunity Canvas: Agile Opportunity Canvas also referred to as Agile Project Charter is used to ensure whether the business value is captured in the right format, which gives visibility to higher management and decision makers to ensure the investment is made to the right effort. An opportunity canvas is similar to a lean business case. It will help us capture the essential fields. Drafted opportunity canvas will move through the approval process before any project work is initiated. Sample Agile Project Charter template:There are different elements in an Agile Project Charter. These elements are customized according to the Organizational needs. Opportunity Canvas is a living document and it should be in One page.In a nutshell, we should have the required elements populated to move it across the Demand Management. Generic elements to be part of the Opportunity canvas are listed below:Current Problem Statement – Why do we need to implement this idea? What is the Problem statement?Strategy/Value Justification – What is the value proposition this idea provides and what strategy are we adopting.Scope – In scope and Out of scope details for the generated idea/ enhancement.Sponsors and Stakeholders – This could be internal or external to the organization.Financials – What are the costs and benefits associated?Success Metrics – SMART Metrics towards the investment. (Specific, Measurable, Achievable, Realistic, Time related)Resources - Who are the resources going to be engaged? What are the procurement needs? What are the infrastructure needs? Etc.,Agile Project Charter Benefits:Agile Opportunity Canvas creates transparency across the entire organization.Provides a rational route and logic of purpose to the entire team from the beginning to the end.Product Portfolio is maintained and prioritized effectively.It helps avoiding duplicate efforts.It also helps in identifying, if the idea/project/ feature is the latest trend in the market.Agile opportunity canvas can be updated during the planning phase and execution phase. During evaluation or closure phase, the project or solution is validated against the success metrics scripted in Opportunity canvas. Success Metrics in Opportunity canvas does not need to be Objective (directly related to Monetary benefits) all the time, it can be subjective (related to value achieved) as well, depending on the nature of the solution and project.
Rated 4.5/5
based on 1 customer reviews
172
- by sayee krishna
- 12 Sep 2018
- 4 mins read
I would like to start this blog with a question. ... Read More
When Can You Expect Your Newly Formed Team To Perform?
By Suraj Sharma
I can visualize the curious facial expression of the readers out there especially if the reader is a Team lead or Manager or Delivery Head. Jokes apart! It’s a quite common scenario whenever a new chunk of work comes to an IT-Farm. A team is formed which starts focusing towards project execution. Once a team is having visibility of the requirement, a ballpark estimate is given to the client. Looks like the team is all set to perform right from outside? Hence the leadership team (inclusive of the Team lead, managers, delivery head etc.) start expecting output. Thus, unknowingly an unhealthy pressure gets built up on the team. Hold on for a second. Aren’t we expecting that with an introvert mindset? Let’s have a look at the ground reality and consider the below model. A team when formed passes through certain stages. We can consider it as a “Tree life cycle”. Whenever we plant a seed it requires extra care and nourishment. After some days of watering and care sprouts starts coming out followed by which, with time, it becomes strong enough and gets converted to a tree.Similarly, a new team when developed passes through the below 5 important stages- 1. Forming2. Storming3. Norming4. Performing5. Adjourning Let’s talk about different stages of team productivity in details:1st Stage: Forming A team enters the forming stage when it is newly formed. Members of the team meet each other for the first time. There is a minimal visibility around the roles and responsibilities of an individual within the team. Hence members are in an “observing mode”, they observe other members of the team to get the feel around the person and how they can contribute together towards the project goal. Team members tend to behave independently since they do not know each other well enough to unconditionally trust one another. Team leader plays a crucial role in this phase. They should define Project goal and should ensure an individual is having clear visibility around his/her roles and responsibilities. 2nd Stage: StormingPost forming stage, a team enters the storming stage where there are high differences among the members due to less acceptance among the individuals. Members think more from an introvert mindset and from an individual perspective. Productivity from the team member is least, members collide more with each other. In this stage, the team leader should first continuously keep track of the work and resolve conflicts. Exhaustive presence and input are required from the leader to ensure that the team is running on the constructive track. 3rd Stage: NormingPost Storming phase, the team enters the norming phase wherein there is a high acceptance around the decision and differences between the member of the team. The team becomes more mature and there is a high collaboration among the members of the team. They work more as a team rather than an individual contributor. There is a shift from an introvert to extrovert mindset among individuals. The team members start building trust towards other members and actively seek each other out for assistance and input. We can call this phase Pre-Performing phase. The productivity of the team is high compared to the previous two stages. The team leader may not be involved in decision making and problem-solving anymore, as the team is working better together and are holding themselves accountable for the delivery. However, on a need basis, the team leader can pitch in and provide direction to the team. 4th Stage: PerformingOnce a team exits the norming stage, it enters the performing stage. Here the focus is more towards achieving the project goal as a group. Here throughput from team members is at its peak. There is a high trust factor, collaboration, and proactiveness among the members of the team. Hence the team takes quick decisions and solves their problems quickly. Thus, there is a timely delivery from the team. In this stage, a team leader is not involved in decision making and problem-solving. From the performing stage, it is possible to revert to the Storming stage if a member starts working individually and is not a good team player. Hence the team leader keeps a watch to ensure that this stage doesn’t change back to storming stage. 5th Stage: AdjourningA team enters this stage when the assignment gets completed and the team can be dissolved. The entire team celebrates the success with the help of different activities ( For eg: Team party ). The team leader plays a crucial role in this phase. The leader should ensure that the members are appreciated for their valuable contribution. Here is how the performance of the team would look like-The above model is known as “Tuckman Model of team formation”.Bringing it all together“A general thought on how often being a Team leader we think of it and accordingly expect productivity from the team?” Let’s re-analyze the current stage of our newly formed team and help them achieve the “Performing” stage by working constructively along with the members, rather than creating an unhealthy pressure of delivering irrespective of the current stage of the team. Please share your thoughts in the comment section, we can connect on LinkedIn and talk more. If you enjoyed this post, spread it to your connections on LinkedIn or other channels. Thank you!
Rated 4.0/5
based on 2 customer reviews
134
- by Suraj Sharma
- 05 Sep 2018
- 3 mins read
I can visualize the curious facial expression of t... Read More
How Not to be Agile – 2. The Business Case
By Steve Ash
Is Agile Everything?‘How Not to be Agile’ may seem a strange title for the blogs mentioning about how good Agile is!The benefits of adopting the Agile methodology are well documented everywhere. What I intend to do over these series of articles is to share with you the misinterpretations, omissions and mistakes that people make. This significantly reduces the potential benefits when an organisation, or part of it, embark on an Agile Transformation.Agile Transformation is not an easy task! Though the ‘mechanics’ behind the Agile frameworks are relatively straightforward to implement, people have trained adequately. However, the root cause of all the troubles that I met is inadequate training and/or coaching of everybody involved with the Agile Transformation including the development people as well as the senior and middle management, both business and technical.Last time, I discussed the potential pitfalls of not having a suitable and visible Vision and Objectives for whatever it is that we are trying to achieve, be it a new product, a major change to an existing product or the Agile transition itself.This time, I will cover some of the omissions, misunderstandings and malpractices that I have come across with respect to the Business Case; an overall product development ‘document’ with which we can track whether the ongoing development is likely to meet the business value outlined or specifically stated in the development Objectives for a reasonable cost; it is no use developing a product for $1 million dollars if it will take 10 years of product use before it pays for itself.I will start with a description of an Agile Business Case and then give examples of what has and could go wrong.What is the Business Case?Having achieved an agreed Vision and Objectives, the business stakeholders and development team need to quantify the business value that is expected from the product, in what timescale, and the estimates of how much it will cost to develop so that that the business stakeholders can determine whether the development is justified from a business point of view.These estimates are recorded in the Business Case; a cost-benefit analysis. In the past, in an effort to reduce development business risk as much as possible, some companies produced a detailed, task level,a project plan with all the ‘who will do what and when’, factoring in known team member holidays etc. By this means, they hoped to establish the probable costs of the development with a high degree of accuracy. However, I have never seen the expected business benefits undergo such a rigorous analysis.Also, I have never seen the Business Case updated periodically during the development so that it can be determined whether the development is still justifiable.This way of producing a Business Plan usually involves a ‘development expert’ to do the technical estimations and takes a significant amount of time during which no business benefit is being accrued.What is an Agile Business Case?“Therefore, ‘experts’ are asked for their opinion about probable or possible costs for different ways of solving the problem:Develop the product from ‘scratch’ – usually the most expensive optionUse an existing product as a ’base’ and modify/configure it – the next most expensive optionOutsource the development – ‘passing risks to some other company’ – the costs can vary significantly depending on the contract type.From these ‘guesstimates’, the development Sponsor can take a decision as to which development option to take. I will discuss Agile Roles in a later article.There is always another option for the Sponsor to take – ‘Do Nothing’; especially if the probable cost-benefit analysis indicates little Return-on-Investment.If the initial, ‘guesstimate’, Business Case cost-benefit analysis indicates that it may be worthwhile continuing with development, development continues.”What is Agile Business Case Lifecycle?Once the initial Agile Business Case has been created it is not ‘set in stone’; like most other things in an Agile environment, it is subject to change as we learn during the development. Indeed, I use a set of development ‘document’ templates, which includes making a business case for Agile, that all have ‘This is Subject to Change’ printed in red at the top and bottom of each page.Post Product Backlog CreationThe Product Backlog, which I shall discuss in my next article, is a list of ‘requirements’ that have been ordered by business value and estimated.These estimates, that have been done by the development team, can replace the costs section of the initial Business Case. The initial Business Case expected benefits can be assessed by a wider stakeholder population and either confirmed or modified.The cost-benefit analysis for the modified Business Case values can be used to, again, assess whether it is advisable to continue the development, modify the Vision and Objectives to obtain a viable Business Case or cancel the development.The time taken from establishing the Vision to achieving this first modified Agile Business Case should be no longer than 4 to 5 weeks; usually, a lot shorter time than is usually taken in a traditional product development environment.At the End of Development TimeboxesA Development Timebox is the short, 2 to 3 week period during which the development team completely develop a subset of the ‘requirements’ and what has been developed demonstrated to the relevant stakeholders. Most of you will recognise this as the definition of a Sprint from Scrum; other Agile Frameworks use different names; I will use the term Sprint during the rest of this article because it is quicker to type!It is recommended that the Agile Business Case be ‘reviewed’ at the end of each Sprint, during the Sprint Review, for the first few Sprints; it is during these first Sprints that the learning curve is steepest. The estimated costs against the actual costs can be assessed and the Agile Business Case updated if necessary. Obviously, assessing the actual benefits accrued at this early stage in development is almost impossible. However, a view can be taken on the new cost-benefit analysis as to whether to continue development.Remember:‘Fail Fast’Once the initial learning has been done, most organisations revert to reviewing the Agile Business Case during the Increment Reviews, done just before a group of functionalities is placed ‘live’; probably every 2 or 3 months.Case Study 1:Many years ago, I was asked to help a team who were building a financial products sales system to replace a company’s current system. The ‘need’ that prompted this development was regulatory in that there had been ‘mis-selling’ of some of the financial products and the government had told the whole sector that they had 6 months ‘to clean up their act’.The company’s current system was based on an ageing mainframe and it was decided that as well as trying to incorporate new regulatory business rules into the sales system, the whole process would be ‘transferred’ to a system using ‘modern’ technology so that additional sales processes could be incorporated, taking advantage of the capabilities of the new technology.The company mitigated some of the huge risks that they were taking on by outsourcing the development on a fixed price basis; the outsource company decided that ‘Managed RAD’ (the precursor of Agile) was the way to go; I was helping the outsource supplier company team.The ‘Vision’ was clear:“To develop a financial products sales system that complies with Government regulation in 6 months so that the company can continue to sell financial products”There was an onsite, senior salesman from the client company to give the requirements for the new system; the equivalent of a Scrum Product Owner.Unfortunately, no one had taken the time to produce a Business Case; it was obvious wasn’t it? ‘New system in 6 months or die’!The prevailing culture within clients and business management at the time was the ‘WISKY’ mentality; “Why Isn’t Someone ‘Koding’ Yet”.That and the 6-month deadline led the team to cut corners on the preparation. Some rudimentary ‘As-Is’ business process modeling had been done to identify where the sales process needed to be modified to include the regulatory requirements as well as where the new parts of the sales process needed to be inserted.The product Owner insisted that as much of the ‘As-Is’ had to be in the new system as well as the new parts.The team decided to go for the ‘low-hanging fruit’ approach, developing the easy and quick parts first; unfortunately, these did not include the regulatory requirements nor the new sales processes.After 2 months of development, the team released the first prototype to the client company to get feedback. The client was very concerned that there was no sign of the regulatory requirements or new sales process and that the team had developed ‘As-Is’ processes that had been in the old system that were there because of the limitations of the old technology, such as overnight batch processing of data.It was at this point that the client was considering cancelling the development contract but they were 2 months closer to the important deadline so it was decided to bring someone in that could turn the ‘mess’ around; that someone was me.I started by investigating the Vision and establishing what was the minimum that was needed in the remaining 4 months. It was decided that a system to support the end-to-end sales process of just one of the financial products, incorporating the regulatory requirements, without any of the new ‘bells and whistles’ would satisfy the regulators and the client company could continue trading.The ‘Product Owner’ was replaced with a less experienced salesman who was not as ‘wedded’ to the old sales process as the previous Product Owner.We established and prioritised the development objectives and put together a Business Plan that was used every week as a means to assess development progress toward the highest priority objective of getting the new regulatory requirements incorporated into the sales process.The new system was ‘finished’ one month early and was demonstrated to the regulators who had high praise and used the new system as a benchmark with which to assess the new systems of other companies in the same sector.During the month left before the deadline other high priority financial products were added to the system; the client deciding that they would suspend sales of the less important products until they too could be added to the new system.Lessons:1) The apparent lack of time always drives people to ‘cut corners’, especially in the preparation. How many window and door frames have you seen that look ‘rough’ because the surfaces were not prepared adequately before applying the top coat of paint? In this case study, some of the people were almost paranoid about the ‘New system in 6 months or die’ so that they focused entirely on the time aspect with little consideration about what the original Product Owner was asking them to do.As a consequence, the team produced a less than satisfactory first prototype.2) Don’t leave the requirements set to one person however experienced they are; the question of ‘do we really need to develop the whole of the new system in 6 months?’ would probably have been asked in the early stages if the requirements setting had been done by a group of people including some developers.3) The lack of prioritised development objectives and a Business Case to assess development progress toward the highest priority objective(s) aided the ‘low hanging fruit’ approach adopted by the outsource company enabling them to effectively waste most of the 2 months work in producing the first prototype.4) On a positive note, however, the incremental delivery nature of Agile had allowed the team to ‘fail fast’. If the team had continued development without customer feedback for all of the 6 months, who knows what sort of system that they may have produced.Case Study 2:I was asked to do an Agile audit in an organisation because one of the senior managers was concerned that he was not seeing the benefits of ‘being’ Agile that were ‘sold’ to him by a chosen ‘partner’ development agency.The development was a programme of work to integrate 12 disparate systems, ‘inherited’ by the organisation by the acquisition of other organisations; the overall aim was to ensure consistency of data across the organisation and allow the use of a data warehouse for decision making.The programme was using an in-house Agile framework based on the DSDM framework. The anti-Agile practices across the programme that I discovered during the audit could make the definitive guide on how not to be Agile.However, I will confine my comments to the consequences of the lack of knowledge on building the Agile Business Case for just one of the projects.The project ‘Vision’ was to automate many business processes that were currently being done manually. When I arrived, the project had been running, on and off, for about 18 months and had not delivered anything. I asked what the project costs to date were and was told that they were in the order of £1 million but this could not be verified because cost accounting in the organisation and for the programme was very ad-hoc.The team was struggling with defining the details of some of the User Stories; several attempts had been made during several workshops to finalise these details before development in one or more Sprints.I decided to sit in on one of these workshops to see what was happening.A ‘Systems Analyst’ was sat in front of her laptop, not shared with the rest of the workshop, and asked questions of the business representatives. They discussed their answers to the questions which mostly were preceded by ‘It depends’. I asked if any prototypes had been attempted for the User Story under consideration and was told ‘we don’t do prototypes because we do not have any prototypers’. I then asked the stupid question ‘What is a prototyper?’. The obvious answer – someone who prototypes! It became obvious that the organisation believed that prototypes had to be produced in code, rapidly.I went to the whiteboard, drew a large rectangle and asked the business representative what they expected to see on a screen, focusing on the most used path through the User Story. In 20 minutes we established the ‘core’ data and business rules for the User Story; it had taken 3 months of sporadic workshops not to get that far.This workshop anecdote led me to ask how this ‘analysis paralysis’ situation had come about. The answer was that the team had ignored one of the basic Agile framework ‘rules’ that development takes place in short, 2 to 3 week, Sprints; the aim of a Sprint is to develop, as fully as possible, a group of User Stories so that they are potentially shippable. As part of the Sprint or Increment Reviews, the business should assess the Business Case to see if it remained viable.Apart from not running Sprints as recommended, the team had a less than adequate Vision and no Objectives on which to base a Business Case. For some reason, which I was never able to fathom out, nobody in the programme or the rest of the organisation was questioning the lack of development progress for this project or the amount of money they were spending for no visible benefit.To cut a very long story short, when an adequate Vision and Objectives were created and a Business Case put together, the business realised that what they were trying to achieve was fundamentally flawed and the project was cancelled.LessonsDespite the poor workshop processes and abandonment of key Agile development practices, the fundamental problem with this project was a lack of adequate Vision and Objectives with which to construct a Business Case by which assessment could be made of development progress toward realising the expected benefits at a reasonable cost.When Vision, Objectives and Business Case were in place, the business realised the futility of the efforts so far and therefore had allowed a waste of £1 million by not having them earlier.ConclusionThese 2 case studies illustrate the worst cases of no Business Case that I have experienced; there are many others.Having tight deadlines or even no apparent deadline does not excuse the lack of sufficient and proper preparation.I discussed the Vision and Objectives issues in the first of this series of articles but these should be used to build a Business Case that can be used to assess development progress toward meeting the expected Objectives for a reasonable cost; developing User Stories is not the aim of Agile; the aim is to develop the right User Stories in the right order.
Rated 4.0/5
based on 0 customer reviews
159
- by Steve Ash
- 31 Aug 2018
Is Agile Everything?‘How Not to be Agile’ may ... Read More