top
Sort by :

Effective Retrospectives : Agile Management

Retrospectives have become a necessity in the world of software development. With things changing so rapidly each day, retrospectives are one of the few means to discover and identify the challenges and highlight the great achievements of a team. The way we need continuous feedback loop for our software products to get better each day, similarly, to create great teams, retrospective play a key role.   Retrospectives or ‘Retros’ as we call it have become a platform for teams to come up together and critically appreciate and review their own work. Many times, the intent of retrospectives is largely misunderstood, it should never be made a platform to point out mistakes of individuals or teams. Also, it should never be a means to compare individuals or teams. That will not only negatively impact the team’s morale and performance, it will greatly influence the individuals within the team.   Tip: Think very well about the participants of a retrospective. For instance, if the team isn’t matured enough they might not be comfortable bringing in points related to requirements in front of the PO or related to processes in front of the release manager. Ideally, there shouldn’t be any qualms in any individual in talking about any aspect but it might take some time for the team to reach that level of maturity.  <iframe width="560" height="315" src="https://www.youtube.com/embed/n_iu8kuA0XE" frameborder="0" allowfullscreen></iframe> Most of the times retros are considered as a waste of time or ineffective by team members. We might even notice that during retrospectives individuals are not actively participating or are not bringing up the real concerns that we might see during sprint executions.   It is imperative to understand that retrospectives should be focused on the following key aspects-  Processes Product Environment These form the bases of identifying the key challenges and opportunities within the team during a retrospective. If any item that eventually doesn’t impact any of the above can be set low on the priority for the team to work upon.   A concern may not necessarily be directly related to the above three but if we perform ‘5 Why Analysis’ of the problem is, we may end up drilling down to the real area of impact and understand the real problem. There is a big difference between actual and perceived problem. The Scrum Master here plays a key role in facilitating the discussion which leads to identifying the actual problem.   For instance, a team member brings out that, “Retrospectives are a waste of time, we spend a lot of time writing retro items. I can work on my sprint deliverables and be more efficient.” After performing a ‘5 Why Analysis’ on this statement we can probably uncover the actual problem. An individual might feel likewise if, ‘the team is overloaded and feels retros take away considerable work time’, or ‘the output of a retro is never worked upon, we never track the action items, hence it adds no value’, or a combination of both. A probable solution for this could be an efficient capacity planning in the first case or through follow-up and active tracking of each action item during the subsequent sprints. Tip: The Scrum Master can coach the team into doing such analysis by themselves to understand the root cause of an issue. This will bring about the true value of a retrospective and will motivate the team to participate in them.   There is no single magic method for conducting retrospectives, it varies with the team’s structure, size, and setup. Following are few of the many techniques that appeared interesting to me or have been used by me. Recurring Retrospectives   These are generally scheduled once each sprint, mostly after the end of a sprint, the whole team sits together and pens down the retro points followed by a discussion and defining action items on the key points. There are several techniques for these, and one can try what suits best for their team,   Went well / Did not go well / Things to try. Continue / Start / Stop Start / Stop / More/ Less / Keep  The idea behind each of these is the same, but how we execute them is different. It works well with co-located teams and brings out the key concerns and achievements of a team. The only challenge is that the entire team needs to think about all the key items for the entire sprint, one might miss a lot of those and the focus might get driven to the one or two major incidents which occurred towards the end of the sprint.   Tip: Ensuring that the team thinks about the entire sprint in totality, we can run through the sprint backlog before we start the retrospective. Focus on each story/defect that was worked upon, the key deliverable, and any challenges that individuals faced during the execution. It helps a lot to bring everyone into a similar thinking space.  Continuous Retrospectives This is a very innovative technique and is more effective than the recurring retrospectives, in terms of time and covering more ground. Instead of sitting together once at the end of the sprint, the team keeps putting down retro points as they encounter them or experience them during the sprint cycles.   These retro items can be either put on a board or dropped into a box as the team may agree to. Now, discussions of the retro item can also be done at regular intervals, or as soon as a specific number of items are identified or even in an ad-hoc manner based on the team’s availability.   With continuous retrospectives, we ensure that nobody spends time thinking and dwelling on the past to write the retro items, everyone can put their thoughts in real time and ensure that most of the crucial items are captured as and when they occur.   Tip: For new teams, it is very important to first perform retrospectives together, that will help individuals understand the thought process and help team define common goals towards being a better team and making better products.   There is no one single best way for retrospectives, but until we keep in mind the intent and desired outcomes of it, any methodology or technique can help us achieve them. Software development today is not just about making world-class software products but is also about making great teams and individuals, and retrospectives are one great tool for us to achieve that.  
Effective Retrospectives : Agile Management
Ankit
Effective Retrospectives : Agile Management 196 Effective Retrospectives : Agile Management Agile Management
Ankit Goyal Nov 21, 2017
Retrospectives have become a necessity in the world of software development. With things changing so rapidly each day, retrospectives are one of the few means to discover and identify the challenges a...
Continue reading

Why Is Retrospection Needed?

The dictionary meaning of Retrospective is &ldquo;contemplation of the past events&rdquo;, i.e. revise and analyse the past. Agile Retrospection is a ceremony performed at the end of every sprint to analyse, document and take actions to make the project and the process more transparent and productive. While Retrospection is very important to any project, it is also important to understand the boundaries created for the meeting team. While setting boundaries we should keep in mind that the freedom of speech of the team is not affected. To understand the concept of Retrospection Meetings better let me introduce you to the basics of the meeting first &ndash; &lt;iframe width=&quot;560&quot; height=&quot;315&quot; src=&quot;https://www.youtube.com/embed/-hnD43Gs_ys&quot; frameborder=&quot;0&quot; allowfullscreen&gt;&lt;/iframe&gt; The Correct Time &ndash; Last day of the sprint is the ideal day to hold the meeting The duration of the meeting &ndash; An ideal Retrospection Meeting should not be more than 20-25 minutes Required Members- Scrum Master, Product Owner, Developers The meeting generally starts with the common parameters of the team like velocity, user stories accomplished etc.Then each member of the team comes up with their opinions on &ndash;&nbsp; What went well? What went bad? What should the team continue doing? What should the team stop doing? Points given by each member is noted in a spreadsheet by the Scrum Master, and at the end of the meeting, 3-4 main action items are selected and are used as inputs to work on in further sprints. In every retrospective, the team should look back at the action items from the previous meetings and ensure that the ones that have been worked upon are closed.&nbsp; While in a new Agile team the members are hesitant to put forward their views openly, in an experienced Agile team it is easier to get the views easily and truly. Having covered all this it is important to understand that sometimes Retrospection meetings are used by employees to cover their mistakes or throw blames at other team members. For e.g. if the work of one developer is dependent on the work of another developer, there might occur a conflict of time or ideas between the two. Similarly, one developer&#39;s work might cause an issue in an existent piece of code written by someone else. These conflicts are often pointed at by developers during the retrospect and thus a healthy meeting turns into an introspection of each other&rsquo;s work in the presence of the whole team and hampers the spirit of Agile. The team participating in the Agile Ceremonies should be trained and coached well to understand the practices advised in Agile and the reason behind them. Many Scrum Masters in today&#39;s day come across situations when differences occur between team members which are not good for the team to perform with complete dedication. In such situations, it is the duty of the Scrum Master to understand the differences and solve as quickly as possible to avoid internal conflicts which may eventually lead to bad team performance or delayed commitments. To avoid such introspection and team differences, the Scrum Master should make sure that the team adheres to the below guidelines &ndash;&nbsp; Always check with the teammates for any issues and try to solve in a mature and professional manner Resolve opinion differences regarding technical issues with logics and backing data Also, before starting every sprint it is very important to understand each requirement from business perspective to avoid confusion Also, it is a Scrum Master&#39;s duty to maintain a professional environment within the team and the Product Owner&#39;s duty to always clarify the business value of each backlog item so that the development team can follow the correct direction from sprint start. There are also some free tools available online like IdeaBoardz, Fun Retro, Reflect, Pointing Poker, Scatter Scope etc. Additionally, below-suggested guidelines for the meeting can help retrospect and come out to better conclusions as to what is best for the team : Each team member should contribute only 2-3 points most important according to their viewpoint When one team member is putting a point others should not contradict or speak in between Everyone should speak when asked to by Scrum Master If a conflict of opinion occurs between 2 team members then the same should be solved with only the concerned members and not to be put in retrospective When a team follows pure Agile, the Retrospective is an important ritual for the team. This helps Continuous Integration and helps the team understand each other&rsquo;s point of view. A Retrospect could also be accompanied by the achievements of the team in the sprint. The Scrum Master can incorporate the team&rsquo;s success in the start of the meeting to set a good tone for the meeting. Concluding, I can positively say that while good Retrospection can do wonders for the team, a bad one can break the team which is not good in the long run. &nbsp;
Why Is Retrospection Needed?
Author Image
Why Is Retrospection Needed?

Why Is Retrospection Needed?

Shreeti Bhattacharya
The dictionary meaning of Retrospective is &ldquo;contemplation of the past events&rdquo;, i.e. revise and analyse the past. Agile Retrospection is a ceremony performed at the end of every sprint t...
Continue reading

Self-Management: The Next Step After Agile

The Agile methodology has gained the interest of multinationals because of its capacity to create digital &amp; non-digital products in a much faster and sensible way compared to &nbsp;before. It opens companies to a brand new way to manage innovation and value creation. The roles and rules connecting employees in the agile methodology change several aspect of the corporate life. Let us build an analogy between the agile methodology and a board game to understand its impact on companies that implement it. In the agile methodology, the rules and conditions are changed but the employees remain the same. The goal of companies using the agile methodology is to is to satisfy customer needs by creating a competitive advantage thanks to speed, adaptability, multifunctional teams and transparency. In the old board game, the ruler or CEO is the person with a vision of what should be done. He is placed at the top of a pyramid, far from the reality of implementation. He has sometimes expectations that cannot be met but he is deaf and blind to (suggestions, explanations, options), which makes communication difficult. He gives orders and expects results in a precise time frame that leads him to control every move or ask for reporting from his leaders crew (Team and department leaders). The ruler is isolated from the workers (team members). On their side, workers are not aware of all resources available to them and they usually have to compete with other departments to get the ruler&rsquo;s attention and resources from the leaders crew. The workers are told what to do without being explained what goal is being pursued. The communication is in &nbsp;one-way: &ldquo;Top-Down&rdquo;. This makes any changes from the workers almost impossible to identify.&nbsp; In the new board game, there are now more rulers. This time, the workers are informed by a specific person (product owner) about the goal they need to pursue. They organize themselves to achieve it, there is no one who gives them specific order all the time or tell them how to achieve their goal. A special attention is given only to the quality of their work. An important idea is that one can learn from failures and incrementally improve upon one&rsquo;s &nbsp;work. The one person who makes sure that the rules and roles are respected is the scrum master. The communication in this game is two-ways, which enables quick change and adaptation. Explained like this we can understand why a lackadaisical innovation exists in the old methodology. The new methodology gives employees, who are doing the real work, freedom to do what they do best on their own term. It also means a big change for the leaders: they must let go of control. Yet with time, training and coaching the agile methodology starts to change the way people interact. It is important to note that the agile methodology is nowadays mostly used in the IT departments, which sometimes creates tensions between the agile teams and the other workers/employees. For example, the agile team may require to budget more often that will drive the financial department crazy because they are still working on the old methodology. The main cause of those tensions is the existence of two different &ldquo;board game rules&rdquo; in the same company. Workers that do not work within the agile methodology see their counterparts make decisions, have fun and freely create their own work conditions because no one tells them how to do it. The feeling of unfairness rises in those companies that have two set of rules. &lt;blockquote class=&quot;twitter-tweet&quot; data-lang=&quot;en&quot;&gt;&lt;p lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;What &lt;a href=&quot;https://twitter.com/buffer?ref_src=twsrc%5Etfw&quot;&gt;@Buffer&lt;/a&gt; Got Wrong About Self-Management &lt;a href=&quot;https://t.co/FKxoBbiQ6z&quot;&gt;https://t.co/FKxoBbiQ6z&lt;/a&gt; &lt;a href=&quot;https://twitter.com/hashtag/agile?src=hash&amp;amp;ref_src=twsrc%5Etfw&quot;&gt;#agile&lt;/a&gt; &lt;a href=&quot;https://twitter.com/hashtag/management?src=hash&amp;amp;ref_src=twsrc%5Etfw&quot;&gt;#management&lt;/a&gt; &lt;a href=&quot;https://t.co/CIOLdvZAhc&quot;&gt;pic.twitter.com/CIOLdvZAhc&lt;/a&gt;&lt;/p&gt;&amp;mdash; Agile Alliance (@AgileAlliance) &lt;a href=&quot;https://twitter.com/AgileAlliance/status/675350779092406272?ref_src=twsrc%5Etfw&quot;&gt;December 11, 2015&lt;/a&gt;&lt;/blockquote&gt; &lt;script async src=&quot;https://platform.twitter.com/widgets.js&quot; charset=&quot;utf-8&quot;&gt;&lt;/script&gt; Agile methodology has limited success since it is just a piece of puzzle. The agile methodology has enabled the creation of quicker, better and client-oriented products and it could bring companies much further if it was implemented across the board. The positive impact of a well implemented agile methodology cannot be denied. One can only wonder when and how it will be implemented in other departments. For example, could the marketing department work within an agile methodology? The answer is yes. The principles developed in the agile methodology were initially put to use in the software industry because the production of software is rapid. Any creative processes that aim to create a final product or service for the benefit of a user will benefit from the agile methodology. I can predict that derivatives of the agile methodology will be forged in other industries such as finance, marketing, etc. The slow transition toward a more agile workplace creates a new context which modifies leaders and employees expectations. So far, companies rely on hierarchical power to make things happen. Now, within this new methodology, employees are free to act on their responsibilities as they wish in order to achieve a common goal. This &ldquo;freedom to act&rdquo; can be referred to as &ldquo;self-management&rdquo;, a term defined by Frederic Laloux in his book Reinventing Organizations. &lt;iframe width=&quot;560&quot; height=&quot;315&quot; src=&quot;https://www.youtube.com/embed/gcS04BI2sbk&quot; frameborder=&quot;0&quot; allowfullscreen&gt;&lt;/iframe&gt; So far, the organizational puzzle was made of silos, bureaucracy and hierarchy while agile methodology puzzle piece introduces the notion of self-management. But what is it? In some ways the agile methodology and self-management have similar ground beliefs: Image Required: Employees are trustworthy Collective intelligence is the new black Transparency is a must Distributed authority makes everyone adept When the agile methodology is a puzzle piece then self-management is the bigger picture. It entails the whole organization structure and redefine its leadership, communication, strategy, change, talent &amp; performance management. Self-management is based on a few core beliefs about employees and their competencies. Employees are trustworthy, mature, driven and capable of learning when put in the right conditions. Self-management is the next level of evolution after the implementation of the agile methodology. I invite you to watch this short video where Frederic Laloux explains the principle of self-management: &lt;iframe width=&quot;560&quot; height=&quot;315&quot; src=&quot;https://www.youtube.com/embed/pneSdqYe53Q&quot; frameborder=&quot;0&quot; allowfullscreen&gt;&lt;/iframe&gt; Self-management is a system of distributed power, where the collective intelligence enables the pursuit of a company vision. &nbsp; I predict the shift from pyramidal organizations--made up of hierarchy and power games (patriarchy)--to a new, progressive and interconnected organization with clearly set rules and roles managed through a clear decision process at the individual level (self-management). Self-management is the next logical step after agile. &nbsp;
Self-Management: The Next Step After Agile
Author Image
Self-Management: The Next Step After Agile

Self-Management: The Next Step After Agile

Anne Cecile Graber
The Agile methodology has gained the interest of multinationals because of its capacity to create digital &amp; non-digital products in a much faster and sensible way compared to &nbsp;before. It open...
Continue reading

INFOGRAPHIC: CSM, PSM and PSD: Certification Features and Benefits

For more information, kindly visit&nbsp;https://www.knowledgehut.com/blog/
INFOGRAPHIC: CSM, PSM and PSD: Certification Features and Benefits
Author Image
INFOGRAPHIC: CSM, PSM and PSD: Certification Features and Benefits

INFOGRAPHIC: CSM, PSM and PSD: Certification Features and Benefits

KnowledgeHut Editor
For more information, kindly visit&nbsp;https://www.knowledgehut.com/blog/
Continue reading

Can ITIL Do Work Well For Smaller Organizations?

While setting up a business in the IT sector, an owner has to decide on the technology and the best practices to follow in IT service management. Some businessmen relate the size of the organization with its capability before implementing best practices in the organization. There is a general perception among people that only larger organizations can use ITIL practices. Let&rsquo;s dig deeper to know whether they are right or wrong. ITIL is defined as a collection of best practices for IT Service Management (ITSM). ITIL consists of a five core books, 4 functions, and 26 processes, that address the problems and thereby improve results. The 5 core books are as follows:&nbsp; Service Strategy Service Design Service Transition Service Operation&nbsp; Continual Service &nbsp; &nbsp;&nbsp;&nbsp; According to Morgan Chmara, research analyst with Info-Tech Research Group, &ldquo;Regardless of size, IT managers and shops do see the benefits of ITIL. The adopt-and-adapt theory is where it&rsquo;s reassuring for smaller business IT leaders.&rdquo; According to him, ITIL is versatile enough to handle various types of requirements of companies of all sizes.&nbsp; The one-size-fits-all best practice framework is the most widely accepted approach to IT Service Management (ITSM). It is said that IT Infrastructure Library (ITIL) provides key skills to help teams and businesses of any size to adopt IT services to figure out changes in the business. However, using ITIL constantly can help the organizations keep pace with the market&rsquo;s needs. Having fewer resources than large companies, small to medium-scale companies assume that they cannot reach out to the best practices. They consider that this framework and practices not only need thorough resources but also its implementation is complex. But this is not a fact. Smaller organizations are blessed with the attributes like flexibility, adaptability, and improved relationships with the customers. But small businesses sometimes fail to identify that these characteristics can provide them an edge while implementing the best practices.&nbsp; Small businesses can find out where they are lagging behind as compared to the large enterprises in managing and optimizing IT investments, mentoring, improving the performance and mitigating the risk, after implementing ITIL&rsquo;s best practices. Generally, small to medium enterprises (SMEs) hunt for the best quality, productive and steady IT services and aim towards delivering these services to the customers. As SMEs can&rsquo;t afford error with the services, they can fix a bug to prevent a future repeat.&nbsp; While adopting ITIL, SMEs need to check out the challenges the organisation is facing and look for quick solutions to sort out the things. &ldquo;Start small and manageable, and implement ITIL processes as per the business demands&rdquo;, is a key to victory for SMEs. ITIL is all about implementing consistently, as its framework allows the use of combinations of a few elements whenever needed. So, it is true that implementing ITIL in small enterprises is a phenomenal process. Undoubtedly, executing ITIL practices is a daunting task, but it fits for organizations of all sizes and can be implemented in a structured way, delivering quality services to the customers. &nbsp;
Can ITIL Do Work Well For Smaller Organizations?
Author Image
Can ITIL Do Work Well For Smaller Organizations?

Can ITIL Do Work Well For Smaller Organizations?

KnowledgeHut Editor
While setting up a business in the IT sector, an owner has to decide on the technology and the best practices to follow in IT service management. Some businessmen relate the size of the organization w...
Continue reading

Incident Management Nuances In Agile & ITIL

Agile incident management is not yet ready to hit the market as organizations are still uncertain of using Agile methodologies to manage the happenings in the IT organizations. Most of the organizations concentrate on the common approach called IT Service Management (ITSM), COBIT and ISO standards. According to the 11th annual state of Agile report by Versionone, &ldquo;60% of the Agile teams are not yet practiced on the Agile methodology, while 80% of respondents said that their organization is at or below a &lsquo;still maturing&rsquo; level&rdquo;. What is Incident Management? Incidents are the unforeseen impediments in the IT workflow. In case the service functionality fails to give an output, it can also be referred as an incident. Incident management consists of a set of activities of process areas like- Analyzing the source of distractions in the IT lifecycle Applying corrective measures to resolve problems in IT services and operations Implementing precautionary measures to avoid incident recurrence Closing an issue after resolving an error Incident Management is the ITSM process area that merely focuses on managing and escalating the incident to restore normal service operations at defined service levels. Incident Management does not have to do anything with problem resolution. The activities that come under Incident Management process are: Detecting and recording an incident Classifying the incident and providing initial support Investigation and review Resolution&nbsp; Closing the incident Incident ownership, observing, tracing, and communication Carrying out incident framework management Evaluation of incident framework management How can Agile Incident Management relate to ITIL Incident Management? If the Agile methodology is incorporated into an incident management process, it will not only automate the lifecycle progress but also reduce the escalation rate of incidents in an organization. An Agile incident management consists of steps like- Lifecycle Management, Data Collection, Association, Description, and Adaptability. On the other hand, an ITIL incident management process consists of steps like inputs, identification, logging, classification, prioritization, initial diagnosis, escalation, investigation and diagnosis, resolution, and closure.&nbsp; ITIL is known as the most-practiced framework in the world, that can be clubbed with the Agile methodology to get a modern tactic to incident management. Referring a thousand pages of documents in an urgent situation takes more time and might need a number of resources in the management process. After applying a set of Agile principles to carry out a &lsquo;planning&rsquo; process from Agile Manifesto, Agile incident management can give the quality products. Iterative cycles: Instead of drawing the same plan for the complete process and clinging to the same, it can be formed in bits which are added when required. This plan can be followed till the requirement is fulfilled. Once it is done, the process is ready to move to the next iterative cycle. Ready for the variant environment: The incidents are unpredictable, but a plan always needs to be prepared beforehand. To be ready with flexible situational updates is an optimized way to handle an incident. According to customer&#39;s&rsquo; feedback, Agile teams will be ready to cope with the changing environment and market demands. Collaboration: The Planning process includes the stakeholder&rsquo;s opinion and participation of the team members. The plan can be changed by frequent discussions with all the parties. Open discussions allow team members to not only focus more on the project but also work collaboratively. Direct Communication: Meetings are considered as a formal part of the project and reading huge documents is not a good idea. Instead, face-to-face communication clarifies the critical matters and solves the issue rapidly and more effectively. . Conclusion: Incidents can arise at any time. So keeping your plans ready is a step towards effective incident management. Adopting changes to avoid occurrences of such incidents can be productive. All organizations can go for Agile methodology to ease their work. Unfortunately, every issue can not be solved by Agile, as it is used for software development process. So you can club Agile methodology with incident management and experience a smooth-operating workflow.&nbsp; &nbsp;
Incident Management Nuances In Agile & ITIL
Author Image
Incident Management Nuances In Agile & ITIL

Incident Management Nuances In Agile & ITIL

KnowledgeHut Editor
Agile incident management is not yet ready to hit the market as organizations are still uncertain of using Agile methodologies to manage the happenings in the IT organizations. Most of the organizatio...
Continue reading

How To Improve Agility With One Simple Change

The principles of agile product development emphasize on the active user and Product Owner/ business involvement. A collaborative and cooperative approach between all stakeholders is also essential. With this in mind, it pays to take a closer look at the collaborative tools used in your development processes. For Scrum Masters who find themselves working with a relatively new team, it makes sense to select tools that will enhance collaborative efforts within the Scrum Team, as well as other stakeholders in the organisation. For Scrum Masters working with a more mature Scrum Team (Product Owner, Scrum Master, and Development Team) and successfully delivering product increments for a number of sprints, making a change in one of your collaborating tools can improve agility.&nbsp; Whether you are a Scrum Master setting up a new team or one that is working with a mature Scrum team, taking a step back and analysing the collaboration tools can take your team performance to the next level. Select the right collaboration software, for more effective agile performance.&nbsp; Top left: Slack, Yodiz, JIRA, Zoom. Here&rsquo;s a guide to what feature each of these tools would need to have so that it can effectively serve the team. 1) Organisation communication tool What is the primary method for communication within the organisation? Is it a real-time messaging tool with file sharing capabilities, or e-mail? Scrum teams should be meeting daily and have face time with the Product Owner. However, after the 15-minutes Daily Scrum, having a business communication tool in place that supports team collaboration provides the ability for constant communication. These quick responses and turn-around time help improve productivity and agility within the team.&nbsp; For organisations using the combination of a chat and e-mail for this purpose, the change to an instant messaging tool for business will allow for these added benefits: Creating small group chat (channels) for improved communication within smaller teams Allows for teams to self-organise, improves collaboration Attaching images, screenshots and other relevant files to the conversation for a more agile development process Integration with the Product Backlog, Sprint Backlog or the video conferencing tool used for distributed team communications 2) Product Backlog&nbsp; The Product Backlog is owned and maintained by the Product Owner or Product team. It is a tool used to gather, discuss and expand on product requirements. In an agile development environment, requirements usually evolve as new data is gathered by the Product Owner. Discussion between stakeholders and the Tech lead takes place. It is beneficial that these discussion threads are recorded to avoid having the Product Owner repeat the conversations that took place earlier. Epics are broken down into user stories and then into more granular tasks, as they emerge closer to engineering sprints.&nbsp; The Product Owner should be able to constantly re-prioritise these granular tasks in the Product Backlog. A simple project management software that enables the Product Backlog Items (PBI) to be dragged up and down the priority list is more efficient than a static list. The Product Backlog software would need to enable the Product Owner to effectively carry out these activities: Easily re-prioritise the Product Backlog Items (PBI) Keep a record of the discussion threads between the Product Owner, Tech lead and other stakeholders for each PBI Estimate each PBI (this is useful to have during the Backlog Refinement meeting) Ensure PBI are visible and accessible to the development team as well as other stakeholders in the organisation, at any point in time A simple Project Management tool would be more effective than a Product Backlog that is groomed on a notepad or a spreadsheet. 3. Sprint Backlog The Sprint Backlog is the development team&rsquo;s interpretation of the Product Owner&rsquo;s tasks. It usually mirrors the Product Backlog. However, each Product Backlog Item (PBI) could be represented by more than one task in the Sprint Backlog.&nbsp; Development team members usually add other tech-related tasks to this backlog.&nbsp; The benefits of using a software development tool and not a physical board (with post-its) to represent the Sprint Backlog are: Development team members are able to access the Sprint Backlog at any given time and location, during the sprint. A sprint backlog represented in a digital format allows for distributed team members. It also allows team members to work remotely. Ease of use and promotes usage. Team members are expected to update the sprint backlog as new information is available. This usually happens daily. The selected software development tool should be easy to use yet powerful enough to provide adequate customisation for your team&rsquo;s preferences. Digital sprint backlogs allow for advanced team data capture and analysis. Most tools come with built-in report generation features. Standard sprint reports such as Burndown chart, Velocity chart, and sprint report are easily generated. For teams using Kanban, Cumulative Flow Diagram (CFD) and Control Chart can be generated. Analysis of these reports can be effectively used at team retrospectives. The definition of done is understood by the team and is illustrated in the columns in the Sprint Backlog (board).&nbsp; 4. Daily Standup If you have distributed team members, or allow Development Team members to work remotely, then a good video conferencing tool is essential to ensure team members are able to communicate well.&nbsp; The video conferencing software can be used for Daily Standup, for distributed teams.&nbsp; &nbsp;
How To Improve Agility With One Simple Change
Author Image
How To Improve Agility With One Simple Change

How To Improve Agility With One Simple Change

Jennifer Ng
The principles of agile product development emphasize on the active user and Product Owner/ business involvement. A collaborative and cooperative approach between all stakeholders is also essentia...
Continue reading

How To Be Successful In Your First Project As A Project Manager

You have been called by your supervisor and you have been asked to manage your first project as a project manager. It&rsquo;s not just luck, it is a result of all the hard work you have been putting in, your ability and confidence that you have gained over time was the reason you were chosen for the assignment. While you are happy to take up the challenge and prove yourself, you are also scared of failure. If you can execute it successfully then it will establish your credibility as a good project manager, else, you may be asked to go back to your old work.&nbsp; We will go through &nbsp;some of the key concepts and tools that a mature project manager uses to help him significantly increase the probability of project success. Credible project schedule Effective communication Stakeholder management Risk planning Credible project schedule Plan, Plan, and Plan. It is being said that you can never plan enough. Although actual project execution will never go as per plan, still planning is a very important aspect. With proper planning, you will be able to start execution with confidence. By the time you finish your planning, you should know answers to the below three very important questions What needs to be done or scope By when it needs to be done or time Do I have the sufficient resources, and time to deliver my project on time with quality? Get answer to the first question from client. Generally, you will also be told the answer to the second question, but you should not take it at face value and validate if the timelines are realistic. Using this information, you need to answer the very important third question. Once you know what needs to be done, break it down into smaller manageable tasks also called WBS (Work Breakdown Structure). WBS is defined by PMBOK (Project Management Body Of Knowledge) as &lsquo;deliverable-oriented hierarchical decomposition of the work to be executed by the project team&rsquo;. Then derive project estimate through the newly created WBS. Even if the project estimate is given to you, you need to validate if it is accurate and if you and your team are comfortable with the same. You can work with an SME (Subject Matter Expert) to come up with an estimate. Make sure that activities like team meetings, reviews, testing, and audits are included in the estimate.&nbsp; Once you have an estimate, based on high-level milestone plan, you should be able to derive team size, resource ramp up, resource ramp down plan and the project schedule. Effective communication It is being said that communication is what a project manager spends 99% of his time on. You need to communicate regularly to all project stakeholders including your team, supervisor, upper management and the client. Communicate regularly with your team to ensure that the tasks are being executed as per plan. Communicate informally during team lunches and formally through e-mails and meetings to get the pulse of the team. Gather not only the progress status but also engage yourself by removing any roadblocks for the team. Keep your management and client informed about project progress as per communication plan. Relevant risks or issues should be communicated through channels such as project status reports and regular reporting. Use communication tools to gain attention and seek help from the management if required. Before going to the management, list down steps you have taken to resolve the problem and any specifics you need from them to solve the issue at hand. As the management may not have time to go through lengthy reports, try to keep them as simple as possible by removing technical details or moving technical information to the bottom. Use RAG (Red / Green / Amber) indicators to communicate project status clearly and in an easy-to-understand manner. Stakeholder management As per PMBOK, stakeholder is &lsquo;an individual, group, or organization, who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project&rsquo;. Any project will have a lot of stakeholders but all of them are not treated equally. It is important to know their position on their power/interest matrix and manage accordingly. For stakeholders with low power, if the interest is low then they just need to be monitored for any change in power/interest. Stakeholders with low power and high interest need to be kept informed as per their needs. Stakeholders with high power but low interest need to be kept satisfied so that they can support the project if required or in case their interest increases. The stakeholders with high interest and power need to be monitored closely and kept engaged. We can also add a third dimension to this matrix called &ldquo;attitude&rdquo; which can be positive or negative towards the project. Stakeholder management is not a one-time activity as during the execution of a project, new stakeholders might get added and existing stakeholders might get dropped off. Also for each of the stakeholders, their position on power, interest and attitude matrix might change and prompt you to act accordingly. It is said that people are the most important and most complex piece of puzzle. Stakeholder management using the above technique is a key to influencing your stakeholders for better support of your project. Risk planning As per PMBOK, risk is defined as &lsquo;an uncertain event or condition that, if it occurs, has a positive or negative effect on a project&#39;s objectives&rsquo;. It is important to understand the difference between a risk and an issue. A risk is an uncertain event which has not occurred yet but has a probability of occurring. When a risk occurs, it becomes an issue and needs to be managed differently. While you will implement the cycle of risk identification, create their mitigation plans and monitor the risk log. Prioritizing risks using impact probability matrix is the key to identifying which ones to focus on. Once you have identified all the risks, they must be rated by their impact on the project and their probability of occurring. Risk probability can be marked as high, medium and low, or any value between 0 and 1. Risk impact can be in terms of cost, schedule or scope. Risk priority is derived by multiplication of impact and probability scores or from the impact probability matrix. A sample impact probability matrix is shown in diagram where green cells show low risk, yellow cells are for medium risk and red cells are for high risks. A risk with higher risk priority score is more important than the risk with a lower score. Once you have arrived at risk priority, risk log can be sorted by risk priority and managed accordingly. Conclusion Things will not go as planned in most of the projects, which is where skill of a project manager comes into picture. The key concepts discussed here will significantly increase the likelihood of project success. Wish you the very best on your first assignment and do share your experience in the comments section below. &nbsp;
How To Be Successful In Your First Project As A Project Manager
Author Image
How To Be Successful In Your First Project As A Project Manager

How To Be Successful In Your First Project As A Project Manager

Suresh Bansal
You have been called by your supervisor and you have been asked to manage your first project as a project manager. It&rsquo;s not just luck, it is a result of all the hard work you have been putting i...
Continue reading

Agile Conflict Resolution Hacks You Should Master

A conflict in an Agile team, usually indicates that the members are actively involved in the team. They either try to drive a change accordingly or raise an issue against the actions of other team members. Conflicts help the teams become more mature and effective. However, resolving a conflict between the team members is becoming more like an umpire between two fighting teams. It is the Agile team, who is responsible for making everybody agree to choose a right solution. &nbsp; The way of handling conflicts is called conflict style. In the year of 1972, Thomas-Kilmann introduced different styles of conflict resolution. At an initial stage, it is vital to understand the different conflict styles before developing strategies for handling the disputes. The five conflict resolution styles introduced by Thomas-Kilmann are Competing, Accommodating, Avoiding, Compromising, and Collaborating.&nbsp; Conflict can be a positive factor if it is resolved potentially. If a conflict is not handled properly, it affects the project by damaging targets, breaking down the teamwork, and eventually the team members disengage themselves from their work. Resolving conflicts successfully will not only help teams solve many issues, but also offer many benefits that are not even expected at first. The benefits of conflict resolution are as follows: Increased Understanding: Discussion on resolving a conflict allow teams to know each other, mount up awareness and search the best talent from the ideas coming out from the team members.&nbsp; Increased team cohesion: After dispute resolution, team members form stronger mutual coordination and increase the ability to work together.&nbsp; Improved self-knowledge: &nbsp; Conflict resolution helps members examine the issue deeply, which enhances their knowledge, sharpens the target, and elevates productivity. &nbsp; But the question is how to facilitate an effective conflict resolution? Following are the possible conflict management techniques, that can help teams manage the disputes smoothly. 1) Engage in personal coaching: Good relationship among team members is important. So always try to treat the members calmly and politely, take efforts in building a mutual respect and always be constructive while separating people and the associated problems. Always pay heed to the root cause. Listen carefully and act. Welcome ideas from the team members to reach to a proper solution. 2. Mentor a team through a conflict resolution process: This conflict resolution technique consists of four steps. Step 1- Set the scene. Initially, you need to identify the recurrent conflict patterns within the team. Guide a team to make them understand that conflict is a common problem and it can be solved by using an assertive approach rather than being aggressive. Step 2- Gather Information.&nbsp; Secondly, listen to others&rsquo; point of view and always respect their decisions. Gather information from the team, understand the conflict deeply and try to find a solution. Step 3- Brainstorm to find out a solution. Arrange spontaneous group discussions to share the ideas on any tasks. Step 4- Confer a solution. This is the last stage in conflict resolution. Through this step, the hurdles may be removed. Follow the &ldquo;Be calm, be patient, have respect&rdquo; principle throughout.&nbsp; Conclusion: Conflicts in an Agile team are considered as the sign of a group of people working in collaboration. Sometimes conflicts are destructive if not handled properly. Positive and assertive approaches help resolve a conflict peacefully, with non-confrontational discussions. Generally, conflicts are resolved effectively when team members try to explore issues and possible solutions and listen carefully to the other members in the team. &nbsp; &nbsp; &nbsp;
Agile Conflict Resolution Hacks You Should Master
Author Image
Agile Conflict Resolution Hacks You Should Master

Agile Conflict Resolution Hacks You Should Master

KnowledgeHut Editor
A conflict in an Agile team, usually indicates that the members are actively involved in the team. They either try to drive a change accordingly or raise an issue against the actions of other team mem...
Continue reading

Role of Float, Leads, and Lags in developing Project Schedule

Introduction This article discusses scheduling terminologies (Float, Leads, and Lags) which are commonly used for developing project schedule and followed by examples for fundamental understanding. This article is developed on the premise that the reader is having a basic understanding of project schedule network diagram, sequencing of activities, and logical relationships between the activities (e.g. Finish to Start, Start to Start, Finish to Finish, and Start to finish). This article is useful to PMP exam aspirants and to practitioners for developing robust project schedule and execute it accordingly. Float, Leads, and Lags are very simple to understand and to apply in our project schedules. However, lack of appropriate knowledge can lead Project Manager (PM) to develop an inferior quality of project schedules and ultimately result in an ineffective execution of it. Conceptual Understanding: Precedence Diagramming Method When it comes to the management of project schedules, the precedence diagram method helps PM to determine project activity flow. This flow of activity helps evaluate logical relationships or dependencies between the various project activities. That also includes evaluating relationships or dependencies between two dependent activities. The concept of Leads and Lags is critical in defining and evaluating these relationships. Leads and Lags worked as modifiers of these relationships or dependencies. Refer the below figure for Precedence Diagramming Method Relation Types. Float Among many project scheduling concepts, Float is one of the key concepts that represents the flexibility of the project schedule. Flexibility in terms of delaying or advancing the project activities. Float simply means freedom or breathing time available in the schedule for PM for executing the project activities. To understand this concept, refer the below-given example. Activity A = 3 Days, Activity B = 2 Days, and Activity C= 3 Days. These activities are having Finish to Start Relationships. That means, when Activity A will finish, B will start and when B will finish, activity C will start. That means Activity C is dependent on the completion of Activity A and Activity B. In the example given below, let&#39;s assume that Activity B is a complex activity and PM has kept 2 days of float to avoid failure of the overall project schedule. Here, this 2 days&rsquo; Float will work as an additional time or breathing time or freedom available to complete Activity B in case any undesired situation&rsquo;s impacts on the execution of it. Please refer below-given illustrations for detailed understanding. As shown in the illustration, let&rsquo;s discuss the various scenarios of using this Float or additional time for executing Activity B and its impact on the successor Activity A and C. Scenario 1: Start of Activity B immediately after finishing of Activity A Let&#39;s assume that PM has decided to start the Activity B immediately after the completion of Activity A i.e. ES of activity B. If Activity B is completed in 2days as planned, then PM will be left with 2 days of freedom or breathing time. In this case, PM can choose-&nbsp; To use 2 days of free time by advancing Activity C. i.e. ES of activity C and complete the project 2 days earlier (8 days) than planned (10 days) i.e. EF of Activity C or To do nothing and to wait for Activity C to start at its planned start time and to complete the project as planned (10 days). Scenario 2: Delaying Activity B after Finishing Activity A. After finishing Activity A, PM reviewed the work progress and found that the project activities are in control. PM chooses to delay the Activity B by 2 days after completion of Activity A. i.e. LS of Activity B. However, in this scenario, PM should have high confidence to complete the Activity B within its planned time of 2 days. Failure in finishing Activity B in 2 days will delay the Activity C and that ultimately may result in the delay of overall project schedule. Scenario 3: Mixed Scenario If the project activities are in control, PM can also choose to delay Activity B by 1 day i.e. LS of Activity B after the finishing of Activity A. If Activity B finishes in 2 days, then PM will be left with 1 day of float. PM can choose to advance the Activity C by 1 day i.e. ES of Activity C and finish the project 1 day earlier (9 days) or PM can choose to do nothing and wait for Activity C to be started at its planned start time. Leads and Lags Now, let&rsquo;s understand this concept in detail. Leads and Lags are nothing but the type of floats (Freedom). Lead It is an activity relationship where successor activity is advanced in order to be conducted parallel to predecessor activity. That means the predecessor activity is still running and successor activity initiates. Let&rsquo;s understand the below-given example. Let us assume Activity A and Activity B has Finish to Start relationship. It takes 1 day to write 2 pages of report. Therefore, estimated time for finishing Activity A (Write a 12-page report) = 6 days. It takes 1 day to review 3 pages of report. Therefore, estimated time for Finishing Activity B (Review 12-page Report) = 4 days. Therefore, for completing this project Activity A and B (Finish to Start relationship), PM will need 10 days. However, if PM chooses to advance the Activity B and start reviewing the completed pages of report from the 4th day of Activity A, then PM will be able to complete the project (Activity A &amp; B) in a total of 7 days. In a nutshell, when the predecessor activity is still running and successor activity starts, this is called Lead. The remaining time of Activity A when the Activity B starts is called Lead Time, or basically, the overlap time between Activity A and B is called Lead time. In the above example, Lead Time is 3 days. This concept is applied as Fast Tracking technique for compressing the schedule. Lag It is an activity relationship where the successor activity is delayed to pass some time right after the completion of its predecessor activity. Lag describes delay or addition of time. Let&rsquo;s understand the below-given example. Let us assume Activity A and Activity B have Finish to Start relationship. It takes 1 day for plastering the wall. Therefore, estimated time for finishing Activity A = 1 day. It takes 1 day for painting the wall. Therefore, estimated time for finishing Activity B = 1 day. Considering this scenario, PM will need 2 days for finishing this project Activity A and B. However, we cannot paint the wall until the cement plaster is set up and dried. Therefore, there will be a need of putting a mandatory delay after completing the Activity A to allow cement plaster to be set up.&nbsp; Let us assume that PM chooses to put a lag of 1 day after finishing Activity A. In this case, PM will require 3 days to finish the project (Activity A and B). In a nutshell, when predecessor activity finishes and if there is a need for delay or waiting period prior to starting the successor activity, then this is called Lag and the delay period is called Lag time. In the above example, Lag Time is 1 day. Here it is quite worth to note that PM does not put lags in the project schedule without any proper justification as no one wants to delay the project. So, Lags should always be considered to satisfy some predefined requirement, condition, or strategic objective of project. &nbsp;
Role of Float, Leads, and Lags in developing Project Schedule
Author Image
Role of Float, Leads, and Lags in developing Project Schedule

Role of Float, Leads, and Lags in developing Project Schedule

KnowledgeHut Editor
Introduction This article discusses scheduling terminologies (Float, Leads, and Lags) which are commonly used for developing project schedule and followed by examples for fundamental understanding....
Continue reading

How To Generate Requirements From Use Cases

In earlier posts, I wrote about user stories that can help capture user&rsquo;s requirements holistically and encompass the needs of your customers; I also wrote that user stories should then lead to use cases enabling your engineering team to get something concrete on paper for building. This is the third and final post in this series: How to generate requirements from use cases. The simplicity of this task can be misleading. If we, as project managers or product managers, fail to accurately translate our refined and well understood user stories, use cases into requirements; then our engineering team is doomed for failure. Why? Because requirements that were being tracked to completion before shipping were not completely and correctly comprehended, in spite of having good user stories and use cases. Hence, it is very simple but an important step where you should get final requirements correct down to the last detail. I could have used the term &ldquo;write&rdquo; or &ldquo;create&rdquo; requirements from use cases; like I did for my post of Use cases but I chose to use the term &ldquo;generate&rdquo;. Why?&nbsp; Because your product or feature requirements should organically arise out of use cases and you only need to start the documentation process to have them recorded; assuming you have done your job correctly. Before proceeding, I humbly request you to please read and understand earlier two posts on &ldquo;how to work with user stories&rdquo; and &ldquo;Use Cases - How they are different from user stories and how to create them&rdquo;. And feel free to raise questions to me by replying to the comments or emailing me directly. Now, assuming that you have read those two articles; let us begin on the last stretch of this journey. What are requirements? Please take 30 seconds and try to put in words; what is meant by the term &ldquo;requirements&rdquo;? Time yourself! I am waiting. Tough! Isn&rsquo;t it? Exactly! Because while we all intrinsically know what requirements mean, we are not able to put them into words and whatever can&rsquo;t be put into words, can&rsquo;t be explained to the audience. Unless we have a way to put our requirements into words exactly the way we understand them intrinsically, we will not succeed in our goals. To begin with, I define requirements as a clear concise sentence of not more than 10 words specifying the most singular unit of demand. A simple example of generating requirements from use cases: Let&rsquo;s continue with the same toothpaste development example from my use cases post so that we all are on same page and mutual mental understanding remains. There we had developed a user story for John, our user, who wanted to feel fresh and energized even after 12-14 Hrs. of work day. And based on that, we had developed some use cases; remember? See the post here. Listing some use cases again here for ease. Use case 1: User wants to have a premium quality feel when he/she takes the toothpaste tube in hand before brushing. Use case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. Now let us generate requirements out of those. Always remember, following things while generating requirements: Requirements should be concise and should contain only one demand in them. A single use case should not be giving rise to more than 2, at max 3, requirements. If a use case is able to generate more than 3 requirements then it is a clear sign that this use case is in fact a half-baked user story and needs to be broken down further. If a requirement cannot be expressed in less than 10 words then it is a use case in disguise and you need to relook at your user stories once again All requirements should have priority. We will be using tabular format so that we can maintain requirement traceability. 1) Requirement number has to be unique and will be used to track the requirement in various forums, discussions and work breakdown structures. Recommended format for requirement number is X.Y where X refers to the use case number and Y refers to the unique requirement within that use case. For example: 1.1, 1.2, 1.3 and so on to depict 1, 2, 3 requirements for use case 1. 2)&nbsp;Requirement description as we know is a clear concise sentence of less than 10 words depicting a single unit of demand 3)&nbsp;Use case generated from allows the product manager and engineering team to know which use case generated this particular requirement and suppose, down the line if use case or user story undergoes modification then we will clearly know which requirements are impacted and require a review. So it helps in that sense. 4)&nbsp;Business priority is not to be confused with task priority. Every task that is a child of a requirement will have its&rsquo; priority depicting the order in which they should be done. So, let us generate requirements for Use Case 1: &ldquo;User wants to have a premium quality feel when he/she takes the toothpaste tube in their hand before brushing.&rdquo; Now, let us generate requirements for Use Case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Now, let us generate requirements for Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. And so on you can develop your requirements. I hope you enjoyed this post as much as I did! ☺ All the best! &nbsp;
How To Generate Requirements From Use Cases
Author Image
How To Generate Requirements From Use Cases

How To Generate Requirements From Use Cases

Abhinav Gupta
In earlier posts, I wrote about user stories that can help capture user&rsquo;s requirements holistically and encompass the needs of your customers; I also wrote that user stories should then lead to ...
Continue reading

SUBSCRIBE TO OUR BLOG

Share Blog

View All Topics

Follow Us