top
Sort by :

Doing Agile In Non-Agile Organizations

The Clash At a first glance we may think traditional management and Agile are misaligned. “Knowing” upfront when a project ends, the full scope and the plan to get it done are strong beliefs that anchor the waterfall solution. We, who have learned waterfall-based project management theory and used it to manage projects, are accustomed to listening and getting induced into thinking that change needs to be managed and the customer educated to stay within the scope and accept a change management that ultimately will increase the project’s revenue. This is, in fact, a tool to lower risk, keep margins and increase revenue. Note that these are beliefs, and sometimes, if not often, they fail to meet the expectations. Margins get crushed, changes happen without customer accountability nor additional sales, deadlines slip, and, in the process, we wear out the relationship with customer. Thus, all sorts of KPIs and tools have been proliferating that try to give information and predictability in order to anticipate problems and give managers the best means and data to decide. So, management needs to see respected some base concepts such as budget stability, revenue increase, respect for the margin, productivity control, cost control, commercial leads generation, foreseeable resource management, risk management, etc. At this point Agile doesn’t seem to offer the same level of comfort. In fact, it radicalizes some key aspects by embracing changes and letting, if not pushing, the customer chose the outcome as the project moves forward, by integrating short cycles and leading the team to change almost anything at each cycle, by advocating the reduction of measurement and bureaucracy to the absolute minimum, to free the team so they can focus on getting the job done and by planning the least and the latest possible assuming that the plan will inevitably change, not once, not twice, but continuously until the end of the project.   The Link Agile is, above all, a mindset. Agile teams set their mind to achieve the result best suited to the customer’s needs, to always improve, perhaps not always but, undoubtedly, to do, learn and adapt fast, so that when you fail to improve you can bounce right back to the improvement saddle. This way of thinking tends to clash with classical management. Is there a way that both can cohabit the same organization? Communication is of the essence. We need information to flow. We need information to be understandable. When two people don’t speak the same language, to facilitate their communication we can find someone to translate. This translator virtue is that he knows both languages and he can listen to one and explain to the other. Note that the term used is explained, and for a fact, the gap between some languages does oblige a translator to interpret and then translate, for there are times when transliteration will not be enough to make the receiver understand. An easy example is to think of a metaphor or a saying used to characterize something indirectly (e.g. “there is no I in team”). So, we can find someone that can translate from Agile to Classical and vice-versa, and if you are thinking that this can be the Scrum Master, well, it may or may not. It could be the product owner. I prefer having someone dedicated leaving all Agile roles as pristine as possible. The main idea is to have an observer that collects data from the team and adds requirements, creating a project image closer to the one expected by the management by, for example, keeping a plan and managing the change by reporting the base line, the change and the remainder to completion both in terms of cost and time. If possible, the translator solution should be a temporary fix. Agile activists need to come forward and push the organization to transform. Evangelize through good examples, openly debating ideas, inviting everyone to experiment and learn. Segregation works, and, if we find a way to fairly compare performances we can even evaluate both methodologies. Isolating the Agile projects and having the organization to accept a different way of leading these projects can give us the required conditions to adopt Agile up to some degree. This means two different chains of management, and at some level in that chain, you’ll need the translator figure to emerge, depending on the maturity of the organization in Agile adoption. For all Agile lovers, the nirvana is to really change the organization into becoming an Agile organization. This is no small job. In fact, it should be a program, a program to transform the organization, a change management program where everyone should undergo a transformation process, preferably, top to bottom. And is also a discussion to deepen in a new article.     The stakeholders’ desires Customers demand Agile Customers are more and more aware that time makes things clearer. As time goes by the need for changes emerges. Imagine a project aiming to redesign a specific site to become more ergonomic, leading customers to buy more. A study based on a pool of consumers is used and decision is to revamp all buttons and links. Sketches and specs are made, and all is defined to implement these changes. As changes are too big, the customer wisely decides to split the project into 5 phases. After phase one the customers’ feedback shows a completely different direction as best suited. The customer has now a better understanding of the best changes to make. This shows to be true for all other 4 phases and even A-B tests are introduced to improve decision making about the final design. Thus, fixing a scope for a long-running project makes little to no sense. Customers want to reduce time span or to be able to change to better adapt to their actual needs, or to have it all, reducing time to market and being able to adapt their roadmap. Agile, along with some other techniques, gives them the continuous improvement, continuously adapting with frequent releases.  Developers demand Agile Having a project manager is connotated with pressure and stress, the management expects the team to deliver on time and on budget, people are asked for estimates and they suspiciously look at this as a tool for controlling and criticizing. Although that is not a management rule, when things get sour we tend to see a focus on blaming and the ones accounted are those who estimate and those who executed. In Agile there is also pressure and stress, but it comes from within, the team commits themselves to finish what they have planned to do, and they all push the limit when necessary, at least in theory. Maybe not all people are suited for Agile development. Some tend to relax and find excuses rather than searching for ways to strive and become better. This stereotype along with others like the student syndrome, according to which, people tend to procrastinate until the last possible moment, forcing them to do overtime to accomplish the sprint goals or even leading them to fail, instils mistrust into management.   #Sprint16 Periscope How to be agile in a non-agile world https://t.co/ySDzoH4agD via @YouTube — Jon Simmons (@jonsimmonssw6) 24 November 2016   Waterfall is also seen as carrying a large burden with endless hours of dealing with bureaucracy that serves to create data for management and it is seen as of no value to get the job done. While in Agile the amount of bureaucracy is controlled by the team (this does a much better job to have people to accept a certain degree of paperwork). The focus on people and on performance is appealing to professionals that want to improve, grow and progress. Non-Agile organizations adopt positional leadership while Scrum allows for leaders to emerge. Non-Agile project teams have a project manager and usually an architect or a technical leader appointed from the start. The Scrum Master is not the team leader but rather the team servant (he/she should be a servant leader, but this is not always the case) he facilitates and should create an environment in which the adequate form of leadership may emerge.   The market demands Agile Adaptation and evolution are of paramount importance. A project or a product based on a good or innovative idea will only survive until someone else makes it better. This means you need to evolve fast to stay ahead, learn fast. Whilst in non-Agile methodologies, one can foresee intermediate deliveries and releases, it is still expected a full product. And once delivered, the team is expected to move to a different set of functionalities. Changing, at this point, is seen as inefficiency, and it is, it is already too late to fail or change and the cost to modify something structural at this point can be overwhelming. This has led to focus on design and analysis, using mockups, prototypes, focus groups, analysis frameworks, etc. On the other hand, Agile methodologies propose to fail fast and learn often. Instead of a fully developed product, each release builds on top of what was built in the cycles before, adding incremental value to the product. Following this vision, a product is delivered several times while it is being developed. At each cycle, the project team has an opportunity to learn not only from the client but also from each other. The client himself has an opportunity to listen to his customers and to integrate that feedback fast. And so, at each release, the product re-aligns its roadmap, perhaps away from the initial objective, but, most importantly, towards a far more adaptable form catering to the real needs of its public.  
 Doing Agile In Non-Agile Organizations
Joao
Rated 3.5/5 based on 4 customer reviews
 Doing Agile In Non-Agile Organizations 442 Doing Agile In Non-Agile Organizations Agile Management
Joao Pereira Feb 22, 2018
The Clash At a first glance we may think traditional management and Agile are misaligned. “Knowing” upfront when a project ends, the full scope and the plan to get it done are strong be...
Continue reading

Should A Scrum Master Be Technical?

A serious matter of debate has been out there for a while. Mostly in the Agile confines. Whether a Scrum Master should have a technical background or not. This discourse took a new turn after one survey result by Scrum Alliance was out in 2015. It revealed that Scrum Masters were mainly dealing with teams wherein 44% were working in software development and 33% in IT.  This, somehow, led to a mass rethinking of the requisites of a Scrum Master, mainly the technical aspects.  While many are of the opinion that a Scrum Master only needs to facilitate Agile team activities, some emphasize the necessity of a Scrum Master with basic technical knowledge. In fact, a whole new cohort of technically sound Scrum Masters has worked wonders in Agile teams in the recent past.  So while an extensive technical knowledge is not a mandate for a Scrum Master, a familiarity with the project-specific domains is no less than a boon for the SM himself and his/her team. A Scrum Master can be either technical or non-technical. Let us view the role of a Scrum Master in both the ways. Should a Scrum Master be technical? Great, thought-provoking blogpost by @barryovereem at https://t.co/4jd6is7XP6: https://t.co/5qMSteApU6 — Christiaan Verwijs (@chrisverwijs) 18 October 2017 Scrum Master with technical background Benefits of a Technical Scrum Master (TSM) A Scrum Master need not necessarily be technical, but an SM with a technical background is an added advantage. A Scrum Master with a technical background means a Technical Scrum Master (TSM) who plays a crucial role apart from a servant-leader and facilitator. An SM is not a team member, but a team coach. A technical coach plays a key role in successful Agile adoption and in identifying possibilities to implement its usage to maximum effect. A Scrum Master with technical skills can involve in the software development activities successfully by understanding it from a technical perspective. A technical Scrum Master: Is capable of building rapport between the teams and team members Knows very well how and when to ask tech-savvy questions and Has the acumen to find out if something is not right It is necessary for a Scrum Master to have basic technical skills in order to communicate with the technical team properly. It can help the Scrum Master develop reliability among other senior management. Issues with a Technical Scrum Master (TSM) The main problem with a TSM is that sometimes he/she creates some kind of problems. Working with a Scrum Master who is a technology expert is like working with complex problems that are better left unaffected. A TSM can affect the Scum team in many ways. He/she may: Act as a technical SME (subject matter expert) and try to handle services Ask team members some questions on their assessments Force the team to adopt and use a particular technology Guide the team on how to disintegrate stories into tasks Guide the Product Owner on how to evaluate the work Try to handle the project that the team is working on Both the team and the organization should understand what a TSM is doing and when he/she is overrunning the bounds.  Scrum Master with non-technical background Benefits of a Non-Technical Scrum Master Q: Should Scrum Master necessarily have a technical background? A: Definitely not It is not a demand that a Scrum Master should be technical, but it is essential for an SM to have excellent communication and management skills. The main role of a Scrum Master is to assist the team to follow the processes properly and the team is completely responsible for the enhancement of its technical practices. A Scrum Master with a lack of technical skills is free from resolving technical problems and delivering technical services while helping the team in finding the communication and collaboration issues and tackling non-technical impediments. A Scrum Master with his/her intelligence would be able to ask thought-provoking and direct questions which would resolve the barriers. A Scrum Master need not necessarily know the domain details that the team members are working within. This is because, everyone is responsible to do certain work, such as: The Product Owner is responsible for having knowledge on what needs to be done The development team is responsible for identifying how to execute this in a better way The Scrum Master is responsible for enabling them to do what they need to do Issues with a Non-Technical Scrum Master Apart from the standard reasons, there are some other reasons for the failure of Scrum Projects. Some of the failures are caused because of a Scrum Master with lack of technical skills. Here is a list of a few reasons: No follow-up with the team on their understanding of the User Stories  An experienced Technical Scrum Master follows up with the team and helps them execute the task. Ignores mapping user stories to a single feature TSM may not be required here, but when the architect is busy with the other technical assessments, that is where a TSM can help to fill the gaps. Acceptance Criteria given by the Product Owner (PO) is taken up without any discussion Sometimes we need to examine whether the Product Owner has taken a comprehensive view while considering the acceptance criteria. A TSM can help here to negotiate the acceptance criteria if in case anything needs to be considered additionally. Unit testing is ignored frequently A Non-Technical Scrum Master does not understand the importance of unit testing. But a TSM understands its essence and helps the team by arranging a meeting on unit testing. No particular plans to address the defects A Technical Scrum Master, sometimes, especially when the team extremely requires time out from the user stories, could update the program on his/her machine, run unit tests, fix the bugs, and finally ask the testing team to check them once. Final Thoughts: Technical Scrum Master or Non-Technical Scrum Master? A Scrum Master is not required to understand the code, but coaching new teams requires some amount of technical excellence. Technical skills help the Scrum coach to teach and guide the team properly in understanding the practices well.     A Scrum Master does not need to be technical at all. He/she should understand the fundamental concepts of software development and be clear about the work process of IT projects. The most essential skill of Scrum Master is to guide the Product Owner and the team on the Scrum Practices and help the team in increasing productivity. It does not entail anything pertaining to technical and coding skills.   
Should A Scrum Master Be Technical?
Author Image
Rated 4.0/5 based on 5 customer reviews
Should A Scrum Master Be Technical?

Should A Scrum Master Be Technical?

KnowledgeHut Editor
A serious matter of debate has been out there for a while. Mostly in the Agile confines. Whether a Scrum Master should have a technical background or not. This discourse took a new turn after one surv...
Continue reading

How To Be A Scrum Master On A High-Performing Team?

This might sound unfavorable for the Scrum Masters! If a team, more precisely, an Agile team is already performing well, what is the need for a Scrum Master at all? Such teams and their managers might dismiss the idea of a Scrum Master altogether. Therefore, to establish yourself as a Scrum Master in teams which were running fine without you can be more than just a challenge.  However, all you need is a few strong strides. A proper understanding of the Scrum Master necessities will help you create the place, your very own space, in successful Scrum teams. The main factors of a Scrum Master in a high-performing team should be clear to you, alongside the unique characteristics of Agile teams. Else, it might be difficult for you to convince the team members as to why they actually need a Scrum Master.    How to be a Scrum Master on a High-Performing Team https://t.co/2pGL0IUxL8 @LinkedIn #agile #scrum #teams — The Working Report (@WorkingReport) 2 November 2017 Characteristics of high-performing teams: The high-performing team should be able to define a team purpose. The high-performing team takes an individual and mutual accountability of the result obtained by the team as a whole. The high-performing team produces a project output collectively. The high-performing team does open-ended discussions and has excellent decision-making capacity. The high-performing team moves with the points discussed in the daily Scrum. Team members should be constructive at every decision produced by other team members. This will eliminate conflicts among the team members. They should see you as an enabler who can spearhead functional Agile teams.  Here is a whole new slew of hacks to explore new ways to make the best out of such teams- 1.Providing a fresh perspective every time: Being an entrant as a Scrum Master in the high performing team, you need to catch up with the details of the organization’s working processes for the sake of you and of course, the team. For acquiring the details from the team (and also about the team), the new Scrum Master should ask some questions to the teammates.This would help him/her learn what the team is following to accomplish a task. Consider one example of a simple question this Scrum Master can ask the team- Why do we work on several user stories and progressing bugs at the same moment?  Very simply, the team members responded that once they finish one task they start the next.  This works, but at times, results in a testing bottleneck. It can be successful if we limit the number of progressing tasks. You have to ensure that the ratio between the tasks in development and testing stages can be managed at all times. This will give you an enhanced productivity.  While gathering the project requirements from the client, a designer can work with the Product Owner and transform the project requirements into visual designs. The Scrum Master can provide a fresh perspective every time on the graphics and workflows to ensure a better performance.  2. Checking daily status: At an entry level, the Scrum Master feels himself/herself as a secondary option in the team especially when he/she is not aware of the team and their working approach. In this case, a Scrum Master has to play a trick to get into the game. But how? Firstly, Scrum Master can keep a record of the daily status of the team members in following ways: How is each team member doing? Stress levels Whether they are individually fit or not Whether team is following Scrum framework properly This will help you understand the team members and their current status.   3. Get ready to help the team personally: Simply checking on the daily status is not enough, being a Scrum Master. Also, calling out orders at the team without keeping any idea of. the present position won’t work. In order to become supportive, the Scrum Masters need to get involved in the high-performing team. They can support QA (Quality Analysis) team in testing the applications in order to build an even higher performing team.  Scrum Master can act as a third eye in finding out flaws in developer’s attention,  Specifying Scrum team roles    Covering the areas which the team may have missed Giving (the team) an opportunity to convey useful ideas to the Scrum Master 4. Manage the backlog: One of the Scrum Master’s roles and responsibilities involves discussing with the Product Owner and the project stakeholders regarding their requirements. Once the designs are created, the Scrum Master can create a list of high-level user stories and add them to the Product Backlog items for use during Product Backlog Refinement sessions.  The Product Backlog should be split into the sections, well-organized and easy to implement. This will furnish the team with a proper visibility towards their work without jumbling up the requirements. 5. Tracking action items during Retrospectives: Retrospectives provide the best way for the Scrum Master to ask questions and unearth the needful. The Scrum Master in the high-performing team can introduce new retrospective techniques after every alternate sprint, which can keep the processes running smoothly. Most importantly, these techniques will help the Scrum teams to- Inspect the team and the processes Discuss healthily Raise the new ideas Pull out action items during discussion This will allow a Scrum Master to remind the team about their incomplete tasks, and also the accomplished tasks weekly.   6. Rejoice in the team success: Scrum is simple, but hard to execute. So it is always recommended to celebrate the success whenever it comes. This will help the team to stay focussed on their target and connect the points between work and target. If the team is high-performing, then being a Scrum Master it is your duty to shout their successes to keep the team more engaged. Last Words- It is not more important that the team should consist of the ‘high-profile individual’ rather than their actual working. Culture plays a vital role in team performance. If there is a defined culture, it will be easy for the team members to follow suit. In case you are using the Scrum framework, firstly ensure that your team knows Scrum. Secondly, the team should follow a proper working culture under the guidance of the Scrum Master. Yes, definitely, an efficient one!   
How To Be A Scrum Master On A High-Performing Team?
Author Image
Rated 4.0/5 based on 9 customer reviews
How To Be A Scrum Master On A High-Performing Team?

How To Be A Scrum Master On A High-Performing Team?

KnowledgeHut Editor
This might sound unfavorable for the Scrum Masters! If a team, more precisely, an Agile team is already performing well, what is the need for a Scrum Master at all? Such teams and their managers might...
Continue reading

Here Are The Questions Scrum Masters And Product Owners Should Be Asking

Being a part of an Agile team is no easy street. Especially if it comes to handling critical roles such as a Scrum Master or a Scrum Product Owner. They are typically at the helm of the organizations and mean a lot to the respective Agile teams. While it is tempting to seek opportunities as a Product Owner or a Scrum Master, there are a few things the aspirants need to take care of. These mostly pertain to the unique roles and responsibilities and the approaches to seamlessly integrate Agile values into the organizational fabric.  Founder of Apple Brook Consulting – Daniel Gullo says, “Certifications are just a way to establish a baseline. Just because someone has an Agile certification doesn’t mean they’ll be good at their job.”  In this article, we have compiled the most common Scrum Master questions and answers, alongside some of the standard Product Owner questions and solutions.    Necessary #Scrum Master questions for an interview - basics: https://t.co/f5mv0iWqXe #agile — Jasmina Nikolic (@Jazilla) 15 January 2017 Two Commonly Asked Questions On Estimates: 1.Can I get an estimate of the time needed to complete this work (in terms of hours, days, weeks, months or years)? There can be answers like- many weeks, which can even take more than a month. But getting an estimate from the team members like- “probably a week or a few weeks” can be good to make a decision if the team can formally estimate that work in a more precise way. 2.How confident are you in that estimate?  From this question, you can assess the-  Degree of confidence of the team members and  Agreement level of the team members If most of the people in the team are 90% confident about the estimate, it is more likely to be accurate than the one where the confidence level is scattered. However, disagreement in the confidence level of the team members indicates that the team rushed to create an estimate, which can be less credible.   Three Questions On Team Discussions: Scrum Masters or Product Owners sometimes want to know, after what level of detailed discussion and thorough analysis, the team has reached that decision. Here are some questions that the Scrum Masters and the Product Owners ask often: What are the three other options you considered before making these decisions? What’s the worst thing that could happen if we pursue this way? What has to go right and what will be the best decision? As a Scrum Master or Product Owner, you don’t need to ask these questions, rather you can overrule the decisions made by the team members. But it is your right to understand the ‘confidence level of the team members’ in making the decision and how aligned they are with that decision. These questions are formulated to bring to light the disagreement among the team members about a decision.  Two Questions On Meetings: ‘If you meet too often, the team will get frustrated and worn down.’ Scrum Master or Product Owner should not call up meetings very frequently. During each of the meetings, the participants should be less. Here are the two questions that the Scrum Master and the Product Owner keep asking: Do we need each and everyone present here? Should anyone else be present here? The first question is concerned about the team members’ attendance at the meeting. Usually, team members think that they should be there in every meeting, even though it is completely irrelevant to them. The presence of the team members in every meeting, however, is not mandatory.  E.g: A Java developer can attend the meeting on the discussion of the ‘latest release of Java’ and whether to upgrade that release or not. In this case, Java-based developers additionally working on related technologies can also participate in the meeting. It is the responsibility of the concerned manager to appreciate those people who are eager to attend the meeting and like to work collaboratively. In such cases it should be ensured that they do not attend the irrelevant meetings. On the flip side, the second question will help you to find out the missing person for the meeting whose presence is utterly needed. One question to ask while roaming around: The Scrum Master should spend ample time in healthy conversations. This is referred as a “management by wandering around”. They can do this whenever they find team members discussing something important related to work. As counterintuitive as it may sound, these sorts of “unplanned corridor meetings” are more effective and impactful than the scheduled Scrum meetings.  E.g. if a programmer and a tester are having an important conversation, the Scrum Master might listen to everything in case he/she can help solve anything.  Does anyone else want to know anything? This question is a mandate and will help the team members dig deeper into the problem or else get the query resolved with the help of team members and the Product Owner.  One question during Daily stand-ups: Finally, here comes a question which can be asked during Daily Scrum especially when the team feels confused about the Sprint burndown chart. Whether they will be able to finish everything as per the plan or not. At this time, looking at the Sprint burndown chart, the SM and the PO may ask questions like: What do you know that I don’t know?  The response to this question might vary from person to person. One team member may react that he/she has not yet updated the time in the tool or they are at the learning stage and require more time to speed up. Last words- Being a Scrum Master and a Product Owner, asking questions frequently is the best way to grasp new things quickly. Also, this gives a clarity about the team members and their work because asking questions divulge more than the making statements. That exactly is how you live Agile!   
Here Are The Questions Scrum Masters And Product Owners Should Be Asking
Author Image
Rated 4.0/5 based on 8 customer reviews
Here Are The Questions Scrum Masters And Product Owners Should Be Asking

Here Are The Questions Scrum Masters And Product Owners Should Be Asking

KnowledgeHut Editor
Being a part of an Agile team is no easy street. Especially if it comes to handling critical roles such as a Scrum Master or a Scrum Product Owner. They are typically at the helm of the organizations ...
Continue reading

12 Common Mistakes Of The Scrum Master And The Remedies 

Today, companies are becoming a part of the massive technological leapfrogging through some of the popular Agile methodologies. When we talk about Agile, people think of “Scrum” naturally. Scrum is the most widely used framework among the popular organizations. These organizations leverage Agile and Scrum methods for a disciplined project management practice, as Agile encourages continual feedback, iterative development, rapid and high-quality delivery and iterative development.                                         “Life of the Scrum Master is full of challenges, Scrum problems, and Scrum pitfalls.” According to the “11th Annual State of Agile Report” by Version One, the following figure states the top reasons for adopting Agile and Scrum methodologies in organizations. The concept is simple but difficult to implement. Being a Scrum Master can be a tough task, if unaware of the Scrum Master’s skills. Here are the most common mistakes of the Scrum Master and the solutions while implementing a Scrum framework: Look out for these 10 common #scrum mistakes with some simple tips: https://t.co/asOR8ZVj00 #agile #lean #scrummaster #devops pic.twitter.com/WUxQHtKhW5 — TO THE NEW (@TOTHENEW) 29 November 2017 1.Scrum Master acting as a Project Manager- In the Agile methodology, companies follow the “Daily Scrums”. Before starting the day’s work, teams gather around the board to discuss the current and the preceding days’ tasks. Usually, team members report on ‘what they did yesterday’, and wait for the Scrum Master’s reply on ‘which task to do today’, instead of self-organizing within the team.   This is where the Scrum Master makes a mistake. He is acting as a Manager, not as a Scrum Master. A Scrum Master should ideally make team members ask ‘what should be finished next?’  2.Scrum Master making decisions for the Team- In most of the organizations, Scrum Masters are recruited by practical experience (generally senior developers and the project leads are given priority) and by personality in terms of communication skills and the sound mind to carry out decisions to keep the project processes on track. Due to this, team members rely on the Scrum Master for each and every decision, which is totally wrong.  Most of the times, teams consist of a variety of different personalities and letting them express their opinions can help to deliver the best. Avoid dictatorship, as it affects the team spirit, stifles progress and results in a lack of communication among the team members. This is one of the common Scrum pitfalls a Scrum Master typically faces during work. 3.Scrum Master holding sole responsibility for the delivery- This is the common Scrum problem usually found in traditional companies, that have recently entered in the world of Agile development. In traditional companies, people were so far following the leadership style viz. ‘Command-and-control’, in which a single person used to be accountable for all the project tasks, making management impediments-free, simple, and more comforting.  Normally, Scrum Master ensures that the developers are inclined to all the project requirements. But when it comes to the responsibility of the Scrum Master to deliver the product, he/she just concentrates on the product delivery, ignoring the quality. To avoid this, stop planning projects individually. Planning is collectively done by the team members. It needs each and every team member to adhere to the commitments, to understand the target and the way to achieve that.   4.Scrum Master acting as a mediator between the Team and the Product Owner- Suppose the team has finished with the daily Scrum and started to construct a functionality which was recently planned for the meeting. But the team is facing some difficulties and needs to discuss with the Product Owner to get an information. At this point, the Scrum Master communicates with the Product Owner to remove communication barriers and furnishes the needs of the team members. After asking the relevant queries to the Product Owner, the Scrum Master relays the same to the team.     In this way, Scrum Master acts as a mediator between the team members and the Product Owner and forms a Scrum solution to overcome communication impediments. 5. Not conducting Retrospectives after every Sprint- One of the principles from the Agile Manifesto states that- “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. Sprint Retrospective is often considered as an add-on, and implemented only in free time. Agile is all about the adjustments, fine-tuning and versatility. It is really very difficult to fine tune if you seek for the adjustments every time. 6. Not removing obstacles at an initial stage- One of the main roles of the Scrum Master is to remove the impediments. The daily stand-ups is the best way to communicate the obstacles to get the task done. But in case these barriers (more correctly, the issues or constraints) are not escalated by the team members, Scrum Master will fail to remove them. Scrum Master should remind the team at the very beginning to present the potential blockades which might delay their work.   So, at the end, you can have several SMs for a team if your combination allows to get the team focused on delivering value and not wasting time on who is the Scrum Master that can help them on removing impediments or facilitating events. — Israel López (@israelagile) 27 November 2017 7. Less/ No daily stand-ups-   The daily scrum is pivotal from several aspects. It allows open communication (face-to-face), collaboration, yields visibility and transparency into the project. So, for every team member, attendance should be mandatory. During meeting, each team member should stick to the following 3 questions-  What did I accomplish yesterday? What will I work on today? What impediments are blocking me in achieving the project goals? It should, however, be noted that the teams do not have to restrict themselves to the above three questions. As per the tenets presented in the latest Scrum guide, discussion-based stand-ups are equally effective and provide insights into the latest happenings in the Scrum team.   Scrum Master Daily stand-ups https://t.co/vlORxTcJoV — Kevin Ackerman (@ackwdw123) 15 June 2017 8. Not strictly adhering to the Agile Manifesto principles- Try to keep Agile startups uncomplicated. According to Agile Manifesto- Agile gives higher value on  ‘individuals and interactions than on processes and tools’. So, Agile projects can be successful without the use of the tools. You can use stickers on the wall, spreadsheets, and manual burndown charts to keep the process simple.   12 #Principles of the Agile #Manifesto by the @AgileAlliance People matters. We are in the ages of uncertainty at work. We need our minds to boost the best of us and businesses #ProjectManagement #teamwork #SustainableDevelopment pic.twitter.com/4yFAOitEYC — Anca Fajardo (@KathiFajardo) 20 January 2018 9. Wrongly assuming an easy transition to Agile- Agile transformation takes time to set up in the organization. It always starts with mess-ups. Transformation includes dealing with the existing corporate and cultural problems like- poor communication, lack of accountability, skeptics, time management, etc. Effective Agile transformation can be a total cultural change. Be patient and ready to embrace the cultural changes. A company's transition to an Agile environment is a welcome and positive experience. But when reality sets in, some resist the change, particularly those in management. https://t.co/kxpyWqBcUB — Joe Little (@jhlittle) 21 January 2018 10. An ill-formed/non-prioritized product backlog- The most common reason behind Sprint failure is a product backlog with status “not ready”. It is also a cause for delivering low value. Making a backlog ready before the ‘next sprint’ is good. Do not let the team run out of the tasks and keep in mind that every task should be prioritized by the Product Owner.Always heed the point that being a Product Owner or a Scrum Master can be time consuming.So set the goals and provide the necessary training on product backlog to the team members.  What's in a Product Backlog? The most critical part of any Scrum project is a well-defined product backlog. How do we effectively define an efficient and productive backlog?https://t.co/QqMyGe9MBm — Dan Tousignant (@ScrumDan) 19 January 2018 11. Not handing over the ownership of daily scrums to the team-  Sometimes, Scrum team keeps some of the product backlog items undone. This results in spilling over of the undone tasks and simply shifting to the next sprint. This happens when a team fails to finish the high-priority tasks. However, Scrum Master and the team should not take it lightly. When they do this, Sprint planning become meaningless. Therefore it is mandatory on the part of a Scrum Master to support his/her team in planning of its next sprint so that they can finish everything on time. Equally essential is to make them feel accountable if they do meet the targets and the stipulated deadlines.   Do Scrum Teams Meet Too Much? One of the most frequent criticisms I hear of Scrum when teaching Certified Scrum Master courses is “Scrum teams have too many meetings.” With daily scrums, sprint planning meetings, sprint reviews, retrospectives and https://t.co/O9t2EUsq5y — Dan Tousignant (@ScrumDan) 19 January 2018 12. Overburdening the Scrum team-  Scrum team works in Sprints. Only when one sprint ends, the next one begins. Under no circumstances should two consecutive sprints overlap. In simpler words, teams should avoid working in the upcoming sprint while the current sprint is still on. To maintain consistency, the team should work at a sustainable pace. A Scrum Master should safeguard the team from going beyond this sustainable pace and tackle any situation that might overburden the members.   Concluding Thoughts- Scrum, as you already know, is one of the largest and promising frameworks in Agile methodology. One can in fact strongly say, a paradigm shift has occurred with the advent of Scrum. It is therefore important for the companies to practise Agile in a correct way to build the products and deploy them faster to the market. Therefore, being a Scrum Master, it is pivotal to avoid the above mentioned Scrum problems to successfully launch the product in the market.
12 Common Mistakes Of The Scrum Master And The Remedies 
Author Image
Rated 4.5/5 based on 9 customer reviews
12 Common Mistakes Of The Scrum Master And The Remedies 

12 Common Mistakes Of The Scrum Master And The Remedies 

KnowledgeHut Editor
Today, companies are becoming a part of the massive technological leapfrogging through some of the popular Agile methodologies. When we talk about Agile, people think of “Scrum” naturally....
Continue reading

How to Launch Your 1st SAFe Agile Release Train

So, you are excited to organize and launch your 1st SAFe Agile Release Train. Understanding the importance, structure, and deployment of ART (SAFe Agile Release Train) is the central of SAFe Agile implementation to scale & successfully implement the complex projects, deliver maximum business values and complete the project on time well under the budget. Just like a train carries its passengers to deliver at set destinations within pre-estimated time at defined cost, ART also helps you carry out the projects successfully; however, before starting the journey with an efficient ART, you must know the principles that govern Agile Release Train.    10 Steps to Launching your First SAFe Agile Release Trainhttps://t.co/dNWUfCwMBd pic.twitter.com/rT8FDhqcoj — Yves Mulkers (@YvesMulkers) 27 January 2018 5 Governing Principles for SAFe Agile Release Train:  ART is the self-organised team of Agile Teams. It is composed of Agile teams engaged in development, security, DevOps, Enterprise Architecture etc. ART plans. It commits & executes the processes following a specific timeframe often called - PI (Program Increment). ART must follow a value delivery model for periodic planning and timely release.  ART must follow a common iteration length within the PI.  ART must know the clearly-defined objectives & benchmarks. ART must follow the culture of continuous system integration. The works completed by different teams must be integrated at each sprint to keep the developments in releasable state. ART must respect customer previews, internal reviews, and system level QA.    Roadmap to Launch SAFe Agile Release Train:  1.Train the SAFe Program Consultants (SPCs): Train your SPCs properly, the change agents responsible for transformation and connecting the Scaled Agile Framework (SAFe) to your organization. SPCs teach all the stakeholders & leaders to drive the ART to its destination.  2.Train the Lean Agile Leaders: Lean Agile leaders are expected to understand and implement the principles of SAFe Agile framework. Lean Agile Leaders are also responsible to lead & facilitate SAFe adoption for improved outcomes. And for smooth transition, you need to train the Lean Agile Leaders up to the best standards.   3.Identify Value Streams and ART:  SAFe Agile Release Train is a procedural system; therefore, you should make all the responsibilities of solution defining, building, validation, and deployment etc clear.  4.Organize ART and Agile Teams:  The roadmap to organize the ART and Agile teams contains different millstones including:   Well-defined ‘product’ with features/components Leadership support Collaboration Minimized dependencies Integration Well-managed DevOps activities 5.Define and Fill All The Roles Of ART Members:   The critical roles of ART members must be well defined to help the Release Train Engineer, System Architect, Product Managers, Scrum Masters, Product Owners perform the best at par with customer’s expectations.     6.Prepare the Program Backlog:   The practice of using launch date as the forcing function makes it more urgent to determine the scope and vision of PI. The scope of ‘what is built’ or PI is defined by ‘Program Backlog’ informing about the upcoming features, architectural work, and NFRs. The gained vision about the future behaviour of system helps you create short stories for Agile teams.        7.Train the Teams Train the teams properly to deliver the maximum values at each sprint. It is the key part of ART readiness to ensure the on-the-time best quality ‘product’ delivery. 8.Conduct PI Planning  PI planning is a face-to-face meeting event; it empowers the Agile Release Train to align all the SAFe Agile teams for the shared mission & vision.  9.Set the Program Calendar & Launch Date  Now you have ART definition. The next task is scheduling your 1st PI Planning event focused on the forcing functions and ‘date-specific’ launch with PI calendar. The PI calendar shows the scheduled activities including PI planning, System demos, ART sync, Inspect & Adapt (I&A) workshop etc.  10.Execute Innovation and Planning Iteration:  Now, you are almost at the destination. Innovation and planning iteration is conducted to absorb the variances in estimates, allot time for innovation, refine backlog and to plan ‘Inspect & Adapt’ workshop.  Conclusion: Launching SAFe Agile Release Train (ART) for the first time can be a challenging and complex task; therefore, before going ahead, you should acquire the expertise by joining short-term SAFe 4 Release Train Engineer certification training designed to guide you through for efficient ART launch. .   
How to Launch Your 1st SAFe Agile Release Train
Author Image
Rated 4.5/5 based on 7 customer reviews
How to Launch Your 1st SAFe Agile Release Train

How to Launch Your 1st SAFe Agile Release Train

Shubhranshu Agarwal
So, you are excited to organize and launch your 1st SAFe Agile Release Train. Understanding the importance, structure, and deployment of ART (SAFe Agile Release Train) is the central of SAFe Agile imp...
Continue reading

Definition of Done (DoD): Why & How To Use It In Agile Project

Definition of Done (DoD) is the collection of deliverables like writing codes, coding comments, testing of units, integration testing, design documents, release notes etc that add verifiable and demonstrable values to project development. DoD helps the Scrum team to identify all the valuable deliverables needed to complete the Agile project successfully on the time. Although ‘Definition of Done’ is the fundamental element of Scrum methodology; yet, a number of Agile-Scrum teams neglect its importance. The blog post spills the beans on ‘why & how to use DoD in Agile project’.  Why to use DoD in Scrum Project:    DoD Helps To Get Feedback For Improvement:   DoD defines all the steps to deliver an increment; therefore, it helps Scrum team members get feedback about the product and processes. The well-defined steps like sprint demo, acceptance testing, functional testing etc generate on the time feedbacks from the product owner. The more detailed Definition of Done helps you get more feedbacks. Definition Of Done (DoD) Improves Planning To Release At the end of sprints, numbers of processes or tasks are found incomplete at one stage or the other; gradually, the undone work piles up to retard the Agile project’s progress.  The application of DoD helps to complete all the undone work within the particular sprints; thus, saves valuable time because you do not need release sprints. Definition Of Done Elaborates Burn-Down Charts In True Colors:    If DoD is not applied, Agile burn-down chart, the  graphical representation of work still to be done, often presents false image of ‘when the software will be production ready’ because it doesn’t account the undone work accurately at sprints. As a result, the undone work piles up in hidden way while the burn-down chart shows the reduction in remaining work. The burn-down charts created with DoD application presents real picture of work done in complete.    Real Value of a #Definition of #Done in #Agile - http://t.co/dN8laZqIRQ Improve your #product, process @ScrumAlliance pic.twitter.com/HcI4P8eunb — Synerzip (@Synerzip) 2 June 2015   Definition Of Done Minimizes The Delay Of Risk: ‘Definition of Done’ helps you minimize the delay possibility because the defined steps in DoD generate on the time feedbacks guiding you to manage all the identified risky items by inspection, adaptation and improvement at an early stage.  DoD Reflects The Agility, Maturity & Quality of Scrum Team: The efficient Scrum team is expected to complete a new feature in single sprint and to release it at the earliest with guarantee of being the best. DoD reflects the agility, perfection, maturity of Scrum team by exhibiting that it releases new feature in every sprint. How to Use DOD in Scrum: 1.Make DOD Essential: To complete the project on the time, make it essential to follow DoD in each sprint review. Walk through DoD for each PBI (product backlog item) to make it “front & centre” for the team members and stakeholders; it will establish perfect understanding with mutual trust between the project development team, product owner and other stakeholders.  2.DoD Checklist: Use DoD as a checklist for each PBI. Only after going through the complete checklist up to the satisfaction, proceed for the next step.   3.Make DoD the Tasks Oriented:  Create a specific task for each DoD element to ensure that you are more focused on DoD items.  Tasks are easier to manage by managing the expanded DoD checklist.  4.Involve PO to Review DoD at Mid-Sprint:  Develop the culture of showing PBI to PO during mid-sprints. It facilitates PO to know about DoD status.  5.Apply  DoD with Retrospective Approach:  Always be ready to improve, and explore the possibility to make the processes more robust. Ask other Scrum teams for innovative concepts that helped them; and, explore the suitability of shared tips in the line of your project.  Conclusion:  The major reason to adapt anti-DoD pattern is lack of awareness about the importance of DoD.  In most cases, whenever DoD is neglected, it bites the project’ progress & quality. Agile and Scrum training helps the project team members to understand the importance of DoD and the strategies to apply it. Therefore, do not take chances, and, use ‘Definition of Done’ as a Scrum tool for improving quality, minimizing delay possibility and building trust with all the stakeholders.
Definition of Done (DoD): Why & How To Use It In Agile Project
Author Image
Rated 4.0/5 based on 5 customer reviews
Definition of Done (DoD): Why & How To Use It In Agile Project

Definition of Done (DoD): Why & How To Use It In Agile Project

Shubhranshu Agarwal
Definition of Done (DoD) is the collection of deliverables like writing codes, coding comments, testing of units, integration testing, design documents, release notes etc that add verifiable and demon...
Continue reading

Is Servant Leadership Part And Parcel Of A Scrum Master's Daily Life?

Each of us is always a part of some group whether we are at home or at work or wherever we are and I believe that the results are maximized when we work together in achieving our project goals. Quite the same is the case of a Scrum Master, who is also known as the “Servant Leader”. A leader who leads and serves at the same time. This article mostly revolves around the different aspects of a servant leader’s role. The first and the most essential step is to understand the “serve” model followed by a Scrum Master.  Go through the SERVE model provided below, which was created by the author and renowned management expert Ken Blanchard. This model will let you execute Servant Leadership practices in the organization. SERVE is an acronym for: S – See the future,  E – Engage and Develop Others R – Reinvent Continuously V – Value Results and Relationships E – Embody the Values  The term “Servant-Leadership”  was first coined by Greenleaf (1904–1990) in 1970, in his essay titled "The Servant as a Leader." What does a Servant Leadership mean? ‘The servant-leader is a servant first’. The motto behind the philosophy is to stay focused on the needs of others, caring for people, providing an environment where the competent and impotent support each other to build a good community.  Servant leadership is most likely associated with the participative leadership style. The definition of Servant Leadership can be put as a lifelong journey that includes the discovery of one’s self, an enthusiasm to serve others, and a commitment to lead, keeping a focus on the satisfaction and the performance of the employees Servant Leaders lead with others in mind. -Skip Prichard In modern days, you’ve got to produce more for less, and with greater speed than you’ve ever done before. The only way you can do that in a sustained way is through the empowerment of people. And you will get empowered through the high-trust cultures and encourage, support, enable subordinates to unfold their full potential and abilities. Check out this Meetup: Practicing Mindfulness in an Agile Environment with @mameghji https://t.co/rlRHvVkJfl#Meetup#MK138PP#Agile#mindfulness#Scrum#Lean#Innovation#servantleadership via @Meetup — Matthew Moran (@moran_matthew) 9 January 2018 9 qualities required by a Servant Leader       Ten characteristics required for a Servant Leader as suggested by Robert Greenleaf are as follows: 1.Listening: Servant Leader needs to have a long way commitment to listening attentively to others.  The ear of the leader must ring with the voices of the leader. -Woodrow Wilson    The following 10 guidelines, adopted from Thill and Bovee’s book, will enable you to improve as an audience- Minimize both internal and external distractions Adjust your listening to the situation Show that you are listening through your non-verbal communication Determine the pivotal points and plan a procedure to recall them Show your concern Do not jump into giving advice Do not interrupt Do not prejudge an individual’s message by his appearance Stay focussed on the subject Remain clear headed even if the topic is emotional.  2.Empathy: Servant Leader needs to accept and recognize people for their special and unique spirits. Empathy is- “Seeing with the eyes of the another, Listening with the ears of another, and feeling with the heart of another”.  Here are a few hacks to develop empathy- Imagine you being the other person;  Practice caring behavior Converse with people with no personal expectations or goal of fixing them Identify with their experiences by relating to a similar situation which you have been through Heal past damages. 3.Healing: Robert K. Greenleaf in 1970 proposed servant leadership as a way of life in which the focus is on the betterment of others.  Healing yourself is connected with healing others.  -Yoko Ono Following are the few ways that will help you to build healing capabilities- Learn how to deal with difficult situations in terms of serving the common goods Recognize an opportunity to complete those people and organizations you are professionally associated with Care for people and their welfare Choose your words wisely as people may be suffering from lots of personal and professional disturbances on a daily basis Respond to other’s needs Seek feedback. 4.Awareness: Servant leaders need to be aware of their strength and weaknesses. Awareness aids understanding the issues like ethics and values. It lends itself to being able to view most situations from more integrated and holistic position.  Let us not look back in anger, nor forward in fear, but around in awareness. -James Thurber The following are the few ways to develop awareness- If you are not perfect at anything, still you can perform at a high level Make wise and fair decisions without getting influenced by self-emotions and biases Identify your strengths and accept your weaknesses Build the strengths and accept the weaknesses of others Encourage people instead of judging them. 5.Persuasion: An efficient Servant Leader builds group consensus smoothly, clearly, and persistently. The servant leader does not exert group compliance through position power.  The following are the ways to develop persuasion capabilities-  Utilize personally, instead of applying power to influence followers and achieve the organizational objectives Build the culture of consensus for group decision making Be friendly and always be ready to guide others Believe in learn-error-learn (try and error method) Make people believe that they are accepted and trusted.  6.Conceptualization: There is nothing worse than a brilliant image of a fuzzy concept. -Ansel Adams The act of conceptualization is an act of thinking through, seeing beyond the existing, and discovering something new. Servant leaders keep up a delicate harmony between conceptual thinking and an everyday-centered approach. The servant leader must have a dream and an ability to portray it in a vivid language. For any great things to happen, there must be a great dream. Dreams raise the thinking power of the people. The greatest leaders are those who are able to put their dream clearly to the listeners, keep up a fragile harmony between calculated reasoning and an everyday-centered approach. 7.Foresight: Foresight is an attribute that allows the servant-leader to grasp knowledge from the experiences, the present facts, and the likely effect of the future decision. One can have only as much preparation as he has foresight. -Jim Butcher Here are the ways to build foresight- Identify the changing trends, its cause and impact Explain the vision to the team to engage themselves in achieving the vision; Identify different scenarios and check if anything can be done today which can help them tackle future scenarios. 8.Stewardship: Servant leadership is like a stewardship, which assumes commitment as a foremost part to accomplish the need of others. It additionally stresses the utilization of receptiveness and influence instead of control. Stewardship as a leadership behavior leads to successful organizational performance.  Whatever you are, be a good one. -Abraham Lincoln Go through the following ways that will help you to develop Stewardship qualities- Leader’s success always depends on the team’s success Committing to the organizational goals that will help you achieve success Help organizations to become a center of learning and collaboration; Being responsible and accountable for results;  Utilizing and managing all resources. 9.Commitment to the growth of the people: Servant leaders trust that individuals have an inherent value beyond their unmistakable commitments as workers. Therefore, the servant leader is profoundly dedicated to the development of every individual inside the organization.  Stay committed to your decision, but stay flexible in your approach. -Tom Robbins  Following are the ways to develop commitment to team- Appreciate the ideas and suggestions given by the employees Encourage team involvement in decision making Identify growth opportunities for the team members Encourage and motivate people in achieving organizational goals Be committed to helping the team members grow Connect to the others’ developmental needs and actively find ways to meet those needs. 10.Building Community: Servant leaders believe that organizations need to function as a community. A servant leader instills a sense of community spirit in the workplace.  Strength lies in differences, not in similarities. -Stephen R. Covey By following ways you can build the community- Develop the culture of knowledge sharing Develop a learning community Treat everyone equally Build the team to support each other Socially connect with each other Care for each other Appreciate each other’s success Always be there for each other   Summing it up: At last, Leadership is a choice. Before trying to become a servant leader, you should remember that an effective Servant leader always understands every aspect of the business deeply without distracting in attaining long-term goals.  
Is Servant Leadership Part And Parcel Of A Scrum Master's Daily Life?
Author Image
Rated 4.5/5 based on 5 customer reviews
Is Servant Leadership Part And Parcel Of A Scrum Master's Daily Life?

Is Servant Leadership Part And Parcel Of A Scrum Master's Daily Life?

Sandeep Kshirsagar
Each of us is always a part of some group whether we are at home or at work or wherever we are and I believe that the results are maximized when we work together in achieving our project goals. Quite ...
Continue reading

Water-Scrum-Fall: Is it a Myth or Reality?

Usage of Agile Methods for software Development has caught on like wildfire. Every organization wants to follow Agile methods for software development projects to gain all or some of the following advantages. Faster Software Delivery Continuous Customer Feedback and Optimization Improved Software Quality Improved Communication with Users and Business Sponsors Accommodation for Continuous Changes Early Return on Investment  Continuous Visibility on Features Being Developed Optimized Risks Though usage of Agile Methodology has caught on, software development organizations have implemented Agile methods as per their own convenience and suitability by tweaking existing waterfall processes. Hence the term Water-Scrum-Fall.  Through this article, I will take a look at how Agile methodology is adopted in software development organizations and what modifications are made to the pure Agile processes to suit the adopting organizations to get optimum benefit. I will explore the topic through existing literature and my own experience of working in the IT industry. Software development organizations adopt Agile methodologies based on various factors. Some of the factors are listed below. Benefit from the method and maintain leadership position Pressure from competition Risk of losing out on the latest methods and trends Client Demand Internal cost pressures, Agile methods might be a win-win solution Some organizations embark on the journey to adopt Agile methods by following the classical and complete method of adoption. The stages of adoption followed by these organizations are shown in Figure 1. Figure 1 – Stages of Agile Methodology Adoption As can be seen from Figure 1, the standard process of adoption starts at pre-adoption phase with inception and goes all the way thru Execute-Deliver, gaining Insights along the way by learning about measures, data and feelings. Organizations learn through the process during initial iterations for pilot projects. The learnings are applied to future iterations of the process and process matures. Organizations continuously perform analysis of return on investment and perceived gains from Agile method adoption. This helps them to make any changes to adoption method to optimize the gains.  Agile transformation methods and experience gained through Agile methodology adoption is very well depicted through the following Youtube Videos-     So far, the discussion in this article focussed on the traditional way of Agile methodology adoption. Does every software development organization use the standard Agile methodology for the full lifecycle of software development? Do organizations invest in required training and infrastructure to implement Agile for the complete software development lifecycle?  A look at the industry trends reveals that some organizations use an approach with a combination of waterfall and Agile methodologies.  These organizations take baby steps in Agile methodologies adoption. The Agile methodology is tweaked as per the need of the adopting software development organization. Figure 2 shows the model of pure waterfall process adopted by a software development organization. Figure 2 – Steps of pure Waterfall Model Steps indicated in Figure 2 are executed in sequence to execute a software development project and achieve the desired business objective.  As per the adaptation practised by a software development organization, certain steps of the waterfall cycle are implemented using the Agile method. The adaptation is solely dependent on the organization and how it sees the process change fit for the project under execution.  Figure 3 shows the adaptation of standard Agile methodology as modified for an organization in the financial industry for a development project for a Large Retail Bank. The adoption was necessitated by this particular project where design and build activities were to be iterated based on changing requirements. The approach allowed necessary flexibility to implement varied design approaches and pass them quickly to build phase to avoid large-scale changes once the complete design was done. Some part of testing activities were also iterated, however, most of the testing followed waterfall methodology as unit testing was covered along with build activity. Unit testing done in an iterative manner helped generate stable delivery of code from build phase to the testing phase thereby allowing the project to maintain waterfall approach for testing and resulted in a very few testing defects. Figure 3 – Water-Scrum-Fall used for project in Large Bank   Another aspect of Agile is how it is perceived by persons performing various roles. Developers and Testers have most work during the middle phase of the project. Independent studies have proven that developers and testers are very quick to adopt new practices. Developers and Testers are also very keen to adopt Agile practices. Primary reason could be that Agile practices provide them with more opportunities to collaborate. This could be one of the primary reasons for the success of Water-Scrum-Fall. Analyst Watch: Water-Scrum-fall is the reality of agile https://t.co/tvdHhmVmus @darth_dread @simpod @8erbacherozzo — Angry Guider (@AndyRuggeri) November 17, 2017 In my work experience in Information Technology industry, I have also come across examples of the approach outlined above as Water-Scrum-Fall being used. It allows the flexibility of Agile with the right tweaks needed to make it effective for a particular software development organization and a specific project. I have seen this approach being extensively used in regulatory and legal compliance projects for software development for Banking and Telecom industry clients. These projects usually have Designed, Build and Test activities done with an Agile approach. Some projects even include Releases in the Agile approach and adopt phase-wise releases. This approach proves to be more beneficial as the final product is also developed iteratively and has more flexibility to adapt to changes in the life of the project.  Summary: I have covered all elements of standard Agile adoption process and steps followed by software development organizations to adopt Agile methodologies. Some organizations tweak Agile processes to adopt them for some part of software development life cycle, thereby giving rise to the term Water-Scrum-Fall. Organizations have found their own way of adopting Agile methodologies by the way of Water-Scrum-Fall. Experts, however, warn that Water-Scrum-Fall is fine as a starting point but it should not be the end goal of the Agile journey of an organization. The full potential of Agile can be realized with complete Agile adoption by truly embracing Agile manifesto (http://agilemanifesto.org/) and its guiding principles. However, Water-Scrum-Fall is a reality and is here to stay as organizations have found benefits from adopting the methodology.
Water-Scrum-Fall: Is it a Myth or Reality?
Author Image
Rated 4.0/5 based on 4 customer reviews
Water-Scrum-Fall: Is it a Myth or Reality?

Water-Scrum-Fall: Is it a Myth or Reality?

Raju Dhole
Usage of Agile Methods for software Development has caught on like wildfire. Every organization wants to follow Agile methods for software development projects to gain all or some of the following adv...
Continue reading

Writing Effective User Stories in JIRA

User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements to be able to write effective and detailed enough user stories. The user stories are required to be comprehensive enough to enable the developer/development team to start analyzing, designing and developing the required functionality, feature or requirement stated in the user story.     This article while intending to guide individuals on how to write effective user stories is also intended to advise on the best practices of creating user stories using JIRA as a requirements management tool for creating stories and tasks. What is a User Story?   User stories are short, simple descriptions of a feature in the system under development told from the perspective of the person who desires this new capability. This person is normally a user of the system or even a customer who pays for the solution.  User stories typically follow a simple template as below. As a <type of user / user role>, I must be able to <some goal / feature> so that I can <some reason / benefit>.  User stories are often written on index cards or sticky notes and pasted on an information radiator or in other words a scrum board. This article is however on maintaining user stories using JIRA and on how the tool can be used to ensure regular conversation.  Writing user stories on an index card is actually the ‘Card’ part of the 3 C’s in user stories. It is said that a user story should be long enough to fit into an index card and be detailed enough to arouse discussion. Writing user stories in JIRA A new user story in JIRA can be created by selecting the option to create a new issue of type ‘Story’ as shown below.  The user story in the format listed above can be written in the summary field of the new issue creation screen.  User story definition should satisfy the INVEST criteria which implies that the user stories should be: Independent (of all other user stories and be able to exist on its own) Negotiable (not a specific contract for features but be able to be used to facilitate discussion among relevant stakeholders) Valuable (create some business value) Estimable (to a good approximation) Small (so as to fit within an iteration) Testable (in principle, even if there isn’t a test for it yet)   Trace your Customer Requirements to user stories in Agile through the integration with JIRA. https://t.co/esXyAJykZy pic.twitter.com/DZoa1tJrjL — Visure Solutions (@VisureSolutions) 21 November 2017   JIRA also provides the option to set priority of user stories which might have been done based on the MoSCoW criteria, due dates, assign the story to a team member of the project, allocate a story point/hour based effort estimation for the story, tag the user story to a component level feature or in other words ‘Epic’ and be able to assign the story to a sprint during which the story is required to be implemented. Adding description to user stories The 2nd C of the 3 C’s in user stories that is ‘Confirmation’ is used to specify the acceptance criteria of the user story. An acceptance criterion is used to ascertain when a particular user story can be marked as done and is normally used by the product owner to validate the same. The acceptance criteria also help the development team implement the business rules, functionality and will be the single point of reference for the Quality Assurance Team. The description field in JIRA issue creation provides space for the user to specify the acceptance criteria.   Gearset’s Jira Self-hosted (on-prem) and Jira Cloud integration lets you automatically post deployment updates to your tickets & keep up-to-date with the progress of your user stories. https://t.co/qvDlNK5LLr pic.twitter.com/yh8RmUL1Gm — Gearset (@GearsetHQ) 29 January 2018 Enabling discussion Another main aspect of writing requirements as user stories is to enable conversation about the feature among relevant stakeholders. This is known as the ‘Conversation’ component of user stories which is the 3rd C in the 3C’s.  Often user stories are accompanied with a process diagram, UI wireframe or a mockup, data dictionary etc. which can be added as attachments in JIRA or even be associated with the story as comments, wiki page links maintained in confluence. Conclusion Writing user stories is an easy method of maintaining requirements in a dynamic environment of an Agile project. JIRA, as explained above, provides a powerful and rich set of features which helps manage requirements in an efficient and convenient manner.    
Writing Effective User Stories in JIRA
Author Image
Rated 4.0/5 based on 4 customer reviews
Writing Effective User Stories in JIRA

Writing Effective User Stories in JIRA

Rumesh Wijetunge
User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements t...
Continue reading

Challenges & Solutions of Outsourcing the Contracts in Agile

While contracting for Agile development, both the parties agree on the scope & vision at the outset but the project is developed iteratively. The traditional contracting practice seeks to agree with “what” & “how” about the project but Agile contract agrees just with “what” leaving the “how” to be managed at  the development stage by both the parties. The traditional contracting approach is focused on collaborative working rather than procedural working; this philosophy encourages going ahead with a flexible & innovative approach to software development. Still, in most cases, buttoned-up Agile contracting approach doesn’t work up to the satisfaction level. So, what are the most experienced challenges and the time-tested solutions to overcome the hurdles in outsourcing the Agile contracts?   Challenges of Outsourcing the Contracts in Agile:  Signing the ‘Time-&-Materials’ contracts for Agile software development is the most used practice, but it has some serious flaws also that create complex challenges for the buyer (outsourcing vendor) and seller (client) both:   In most cases, contract is awarded to the seller who takes full ownership with responsibility for managing all the risks. The seller executes the project with outsourced human resources in ‘Time & Material’ (T&M) model.   The client owns and manages the project; therefore, the client hires the high number of IT professionals that results in unexpected and unaccounted increase in operational cost.   The buyer has very little scope to add more values at different stages of project development despite feeling capable of delivering more. To sustain the estimated profit ratio, the project managers at client’s side overburden the buyer with more work superimposing new stories; it results in low-quality & delayed software development.   The pressure to complete the project with estimated profit ratio despite several changes in workflow and scope wears down the outsourcing vendor; thus, damaging the project development and quality.    Under Agile environment, it is expected that as the knowledge level of engaged Agile team members increases with the passage of time, they should deliver more with enhanced velocity; this approach doesn’t take into account the pressure of coping with new developments after Scrum meetings.   Experiencing such complex problems, the organization (buyer) decides to shift from Agile approach and to return to traditional waterfall model.   No doubt, Agile is more advanced software development model than to waterfall model but everyone likes to adopt the hassle-free model. So, what you need to do differently for successful and profitable outsourcing of Agile contracts? Solutions for Hassle Free Outsourcing the Contracts in Agile:  1.Buyer’s Responsibilities: Agile is built for long-term partnership nurtured with honesty and trust; if the buyer is contracting Agile project just for a short period, Agile model wouldn’t deliver the expected benefits. Agile implementation needs the mindset change of all the team members; investment in training and introduction of Agile tools will make the Agile team members more confident to perform better with gained technical excellence. 2.Seller’s Responsibilities: The trust between the seller and buyer is the key to success in an outsourcing environment. Agile team members must be free to accept the roles and responsibilities in their due capacity to avoid any pressure to deliver more than their capacity.  3.The Key Agile Contract Parameters: Team size, sprint duration, procedure of identifying team’s velocity, story point standards based on scaled complexity, DOD (definition of done) etc are the key specifications that make outsourcing the contracts in Agile a pleasant experience.  4.Hybrid Styled Contract for Outsourcing Agile Project: Agile project development can be stipulated into two stages in the context of outsourcing - stabilizing period and post-stabilizing period. You can choose to work with ‘Time and Materials’ (T&M) model during stabilizing period with an agreement to switch over to ‘Pay-per-story-point delivered’ model during the post-stabilizing period.  Summary:  To improve the success rate of any Agile project, it is a must for the outsourcing vendor and client both to be equal partners in tasting the success and failure of project. The journey to Agile adoption is about accepting the changes in workflow, working culture and mindset; and, it takes time and improved skills to accept and incorporate changes. The certified Agile and Scrum training, focused on implementation of Agile development and Scrum practices, empowers you to complete each Agile project within agreed time at the best rate profitability that too without any compromise with quality parameters.  
Challenges & Solutions of Outsourcing the Contracts in Agile
Author Image
Rated 4.0/5 based on 4 customer reviews
Challenges & Solutions of Outsourcing the Contracts in Agile

Challenges & Solutions of Outsourcing the Contracts in Agile

Shubhranshu Agarwal
While contracting for Agile development, both the parties agree on the scope & vision at the outset but the project is developed iteratively. The traditional contracting practice seeks to agree wi...
Continue reading

SUBSCRIBE TO OUR BLOG

Share Blog

View All Topics

Follow Us