Sort by :

How To Choose A Scrum Master?

A common problem most of the scrum teams face is with regards to selecting a suitable team member to become the scrum master for the team. It has become a strenuous activity for some teams, for some a ritual whereas for some others it has become just another activity not to be stressed about. However, giving careful thought to the process of selecting a suitable scrum master will be beneficial for any scrum team with different scrum tools Who is the Scrum Master?  A common analogy when teaching scrum is to refer to the scrum in rugby. The rugby scrum is where the two packs of the two opposing teams lock horns in order to gain possession of the ball. The scrum stays firm when the lines stay upright and strong. The responsibility of the scrum half is to get the ball out of the scrum and give it the direction to be taken by passing it on to the next suitable in line. The agile scrum master’s role is similar to the scrum half. The scrum master is the one who gives the team the correct direction and helps them achieve objectives of the project by guiding them in the correct direction. The scrum master is expected to be the protector, problem solver and process consultant for the scrum team. When to select the scrum master? So when is the most suitable time to select a scrum master for the team? Like with any project the work begins once the contract has been agreed upon and signed between the two parties. This precedes analysis of the problem or opportunity, analysis of the stakeholders, identification and agreement on a solution statement and finally the development of a business case.  Once the project is confirmed it is handed over to a scrum master. So, it seems most suitable to assign the scrum master for the project as soon as the project is confirmed and contracts are signed. But is it the case?  It will be much better to appoint a team member who would be involved in the project while the bidding for the project or the proposal stage is in progress. The team member would thus be in the best position to understand the exact requirements of the project as well as the expectations of the client. By again, is this the most suitable person to be nominated as the scrum master? May be, or may be not! Who should be the scrum master? Selecting an appropriate scrum master is prudent for the smooth execution and success of any agile project. First of all lets see characteristics of a scrum master. Problem Solver It is said that the scrum master must be like a road construction worker who is developing a new road. He would need to identify big rocks or thorny areas on the path ahead and be able to clear that path by applying suitable problem solving skills. Similarly, the scrum master must be able to apply necessary facilitation skills, negotiation skills and problem solving skills to remove any impediments that the team may face. Protector The Scrum master must be like the guardian angel of his team. A project team is always pressurized by the client to deliver value within the triple constraints of time, cost and scope. Similarly, the team is pressurized by the management and other teams to take or share team members in other projects. The scrum master must be able to protect his team from such external interferences and allow the team to focus on doing their task. Process consultant The scrum master must be the one who defines and adopts agile processes and practices for the team. As the process consultant the scrum mater must be able educate the team members about the tailoring made to agile practices, be able to guide the team on a daily basis and be able to make necessary process related decisions as and when required. Available and committed The scrum master’s presence is essential for any team to schedule scrum ceremonies, facilitate those events and to guide decision making during those events. The mere presence of a strong scrum master will be a confidence booster for the team. So, if the scrum master constantly takes leave or is not present for team meeting and is busy at other client meetings that person may not be the suitable to be the scrum master. Servant Leader The scrum master is by no means a project manager. The scrum master must be knowledgeable to lead the team by example. He too should be able to contribute to the cross-functional team. Similarly, the scrum master must be a person who sticks with the team during good times and bad. Once, in one of the projects that I was involved in, the team had to work 12 to 15 hours per day for 2 whole months to meet client deadlines. The team was on the verge of quitting when the scrum master himself brought in food and drinks for the team and handed over the items to each team member in person patting them on the back and sitting with them a good 10 to 15 minutes. Changing responsibilities? It is always good to have a change in scrum master role thought the life of the project. This will bring a different perspective and a point of view. However, it is always important to keep in mind the afore-mentioned qualities of a good scrum master and to ensure that the new scrum master does not disrupt the existing good state of the project. As the old adage goes the leader is as good as his team!!.  
How To Choose A Scrum Master?
How To Choose A Scrum Master? 199 How To Choose A Scrum Master? Agile Management
Rumesh Wijetunge Sep 12, 2017
A common problem most of the scrum teams face is with regards to selecting a suitable team member to become the scrum master for the team. It has become a strenuous activity for some teams, for some a...
Continue reading

Use Cases: How Are They Different From User Stories & How To Create Them

I could have used the word, “write” instead of “create” use cases. But I didn’t. If you know why, then you are already expert on this topic, so please do share your opinion and knowledge by adding some comments at the end of this article. If you don’t know why I consciously mentioned “create” instead of “write” then worry not. I will share my thoughts  with you and you can tell me what you think and let’s create a dialogue around it. In my previous article, I had written about user stories, and how they came into extensive usage, how they help develop better products and how they represent users’ voice at forums users don’t have access to. If you have not read that article then I would sincerely request you to read that article first as it will immensely help you in getting the right perspective about this topic at hand. Use cases in simple words are exact statements written in informal manner depicting the specific action that the user is expected to do while dealing with a particular functionality of the product. If you compare this with the definition of user stories I gave in my previous article, you will notice that here I have defined use cases as “exact statements” whereas I had defined user stories as “generic statements” written in informal manner. Why? This is because user stories set a foundation upon which great use cases are created or developed. While user stories try to explain to the engineering team about the environment, goal, role, intention of the user while he/she is going to deal or work with the software; use cases clearly define what the user is going to do here and what result is expected in crisp 2-3 lines. Use cases are one level above requirements. Below is a simple table for quick reference on differences between user stories and use cases. A simple example of creating use cases from user stories: Let us take a very simple example of a toothpaste and let’s create use cases out of it. If you want to see how to develop user story then please read my earlier article on user stories. Always remember, while it will seem easy to create use cases directly from user needs; it is full of pitfalls that might lead to missed functionality and user dissatisfaction later on, after shipping the product. So a user story would look somewhat like this: Actor  :    John, a working professional who wants to keep his teeth health and shiny Role    :    The direct consumer of this product but can influence others by his reviews of a product on his website. Expected results: After brush, John expects his breath to be fresh and teeth and gums to be health for the whole day. Now as you can see, John is a very high impact user for us [The toothpaste company] because he can affect our sales by his review of our product on his website. So meeting his needs are very critical for us. Hence the product manager, should create following user story for this scenario. Sample User Story: It is 6:30AM in the morning and John has started his morning rituals to be ready for work. Daily, his first routine after waking up is to brush his teeth with his favorite toothbrush so that he gets the refreshing feel to do remaining chores around the house and leave for work on time. He likes the way toothpaste, smoothly oozes out of the tube and rests firmly on this toothbrush without spilling anywhere. Also he likes that somehow, every time he brushes, the exact right amount of the paste comes out of the tube. It is never too much and never too little. It’s just right. He feels energized after a refreshing brush ritual and likes the feeling of freshness in his mouth after brushing his teeth. His gums feel rejuvenated, breath feels fresh as he tests it out on his palms. After spending whole day at office, where he had multiple cups of coffee, some food and some sugary items, he comes back home. While refreshing himself, he notices that his breath is still fresh and the taste in his mouth is still neutral without any traces of coffee or cheese pizza he had before. He is so pleased with the product that he has bought for himself, that he decides to write about it in his blog tonight. Now let us create some use cases out of the above user story. Use case 1: User wants to have a premium quality feel when he/she takes the toothpaste tube in their 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. Use case 4: User feels an air of freshness in his mouth after brushing and that freshness lasts for minimum of 24 hours. The feeling of freshness is neither overwhelming nor un-noticeable. It is just mild   enough to provide a feeling of freshness while not interfering with user’s culinary habits. Use case 5: The user is pleased with the fact that the teeth and gums feel very smooth and non-scratchy after every brush. Use case 6: User is happy about the fact that even after 12 hours of intense work day routine, his breath still feels fresh And so on and so forth.  Can you think of some more use cases? If yes, do leave your comment below so that we can discuss on their validity and applicability here. Is the concept of use cases starting to make itself clear to you now and how they are different from user stories? Let us try once more. This time let us try to create use cases of this same product but for different customer base. Sample 2 of creating use cases for a product: This time, instead of a working professional, John. Let us consider Alayah, a teenage girl in high school. Actor :    Alayah, a 16 year high school student who is interested in experimenting new things with regards to body hygiene for better well-being and feeling. Her opinion is slightly influenced by the           feedback of her friends and her own personal experiences as she too likes to share her feedback with them. Role :    A direct consumer of our product and her feedback can motivate others in her circle of influence to try out our product. Expected Results: While healthy teeth and gum are the most basic of her requirements, she is bored with the same tasting toothpastes on offer these days. She wants to try out a new toothpaste that     not only provides her with best dental protection but also convinces her Mom of her ability to choose different but a better product by herself. Here, our engineering team’s task is clear. They need to create a product [toothpaste in this case], that not only impresses Alayah but also provides her with the best dental protection that she needs at her age. Her feedback carries the possibility of our product’s adoption by her immediate family members and her close friends, hence opening the market for us. The product should be unique in itself while being the best in terms of quality at cost effective price, since Alayah is not an earning member of her family. A product manager in this case, will have lot of options to think of a product here and specify to the engineering team. Let us go with one of them. Do share your versions of user stories in this case. User story: It’s morning time and Alayah’s alarm is ringing she had set last night to wake her up on time, if she needs to make it to the school without being reprimanded. She quickly jumps into the shower with a toothbrush having toothpaste on it, while her favorite song is playing out on her personal stereo. While she is freshening up, she is delighted with the fact, even after so many days, her toothpaste continues to give out the same wonderful strawberry flavor that she loves so much. And to add to her delight, her dentist gave her a big thumbs up yesterday on her teeth and gum health. Alayah has been using this toothpaste for a month now and she loves the way, the tube feels like new everyday even after so many uses. She never has to squeeze hard to get the paste out of it. One gentle squeeze and strawberry colored toothpaste gently but firmly oozes out of the tube and rests on the bristles of the brush. Earlier, she used to get lot of scolding from her mother on spilling the paste around the sink, while jumping into shower with toothbrush and paste on it. But ever since, she switched to this new toothpaste, there has not been a single spill ever since. Today, she is definitely going to tell her Mother to make permanent switch to this paste. She will recommend the butterscotch flavor to her Mom because she loves it. Wow! A wonderful experience of morning ritual for Alayah’; isn’t it? Let us create use cases for this one. Use case 1: User is delighted with the fact that tooth paste comes in a flavored version and the flavor of the paste is consistent throughout till the last drop in the tube. Use Case 2: User is experiencing a natural growth in well-being of her gums and teeth due to the regular usage of toothpaste and is certified by her dentist also. The noticeable difference comes out in 1 month of regular usage. Use case 3: The user is happy about the quality of the product and feel of it. The flow of the paste is smooth, uniform and consistent. It is firm yet soft to the right degree and grips the bristles of the       brush firmly without leaving behind any residue. Use case 4: The user is happy with the non-slipperiness of the paste as it holds wells on the toothbrush without spilling on to the floor. Use case 5: The user is going to recommend the product to her family members owing to its cost effectiveness, quality of results and number of flavored options available to choose from. In this case, the product manager’s diktat was clear. The toothpaste should be premium feeling with right amount of firmness, variety of flavored options to choose from, health improving and certified. And how did we learn properly? Because we were able to create user stories and use cases properly depicting the right user environments, their interactions with the system and their expected goals from these interactions. This is how use cases add value to the development of right product whether it is software based or manufacturing based or service based. So next time, when you want to ship to the customer, make sure you have all the right user stories targeting the right audience with complete use cases and your product will be a smash hit. This is why, I said, a product manager “creates” use cases and does not merely “write” them. Because while creating use cases, the product owner gets the feel, intent of the product that will surely be missed out if he/she is merely jotting down the requirements or use cases. In my next article, I will share with you on how requirements come out of use cases. Until then, happy creating user stories and use cases and do share your experiences with me on my email or in the comments’ section below. Thank you for your time!  
Use Cases: How Are They Different From User Stories & How To Create Them

Use Cases: How Are They Different From User Stories & How To Create Them

Abhinav Gupta
I could have used the word, “write” instead of “create” use cases. But I didn’t. If you know why, then you are already expert on this topic, so please do share your opini...
Continue reading

How to Spark an Agile Revolution: 5 Steps to Win the War

A year and a half ago, if projects were our battles, my company was on the losing side.  The battleground of the IT project portfolio at our Company was a mess — ineffective communication, extreme frustration, and stalled projects across the organization.  But then a spark of Agile inspiration — fueled by new Agile tools — ignited an organization-wide revolution. A grass-roots Agile Scrum model has been our winning battle strategy.  This article will tell you the story of an Agile revolution and how we conquered our foes.  Our Agile Revolution was won by chipping away at our disorganized, decentralized, top down project approach, one battle at a time.  I can identify 5 battles that once catapulted our success to win the war to become an Agile company: Battle #1. Convince one individual that the Agile war is a good idea and worth fighting.  Having an organizational Coach or Champion is key.  Many people think of Agile as a buzzword or a fad, or that it doesn’t apply to their particular area of the business.  The core concepts of Agile are universally valuable.  Certainly Agile started as a Development discipline, but it can be successful for any part of the organization.  Fifteen months after adopting Scrum, 86% of Salesforce.com employees were having a “good time” or the “best time.” Only 40% said that before adopting Scrum.  92% would recommend agile to others.  Perhaps employees like agile because there’s 2/3rds less overtime according to University of Calgary research.  At SingleHop, a managed services hosting company, a single Agile Champion turned into 85% of the organization using Agile in 2 years. These are the benefits that Agile promises for everyone. Having a passionate Champion in the organization that understands and believes in the benefits of Agile is the only way to start to formulate a strategy to win the war.   Battle #2. Convince your Generals and Admirals that Agile is a good idea. Not only do you need to have a powerful General to formulate the winning strategy for the organization, but that General needs to be able to get all of the other Generals and Admirals moving in the same direction.  What organization doesn’t want to achieve “higher productivity and lower cost, improved employee engagement and job satisfaction, faster time to market, higher quality, and improved stakeholder satisfaction”?  Reported Benefits of Agile Development – Mountain Goat Software Mike Cohn  But, change is hard and Agile thinking and concepts are very different from traditional ways of thinking, and the ways that companies have always done things.  A commitment from leadership to respect, and uphold Agile, as well as a commitment to invest in the necessary tools, training, and process is required.  Battle #3. Convince One Team that Agile is a good idea, and start using it in the trenches Once you’ve got commitment from leadership, piloting Agile with a team is the next obstacle.  This may involve convincing and training, and will most certainly slow current perceived project momentum down while the team churns with retraining their way of thinking.  But, spending the time with this first team is foundational to moving it to the rest of the organization.  After all, individual and team commitment are the key component of Agile success.  I think Eisenhower was referring to Agile teams when he said “Tell me and I forget, teach me and I may remember, involve me and I learn.” It won’t be perfect, some project casualties will happen.  But, in my experience what emerged from this first team was a model for other teams to follow, as well as an underlying excitement and enthusiasm that infected the rest of the organization.  Battle #4. Enable the One Team with the proper weapons and tools to help them tackle challenges with Agile Teams need the weapons to organize their work, as well as to automate tasks to create organization and as much automation as possible to thwart the enemy.  Enabling the One Team with these powerful weapons, will give them the tools to really embrace Agile.  Figuring out how to apply Agile for the One Team and across the organization is a big hurdle.  This requires investment in time and resources to make these tools successful and possible moving away from legacy tools and ways of doing things.  Some of the most effective weapons in the war are the ones that make life easier for the team, to communicate, collaborate, and create a continuous flow of work.  And making the tools scalable at the outset to be able to share Agile best practices, processes, and resources to create wins across the entire organization is a key battle strategy to create long term success.  Battle #5. Let the One Team's success be your Battle Cry to the rest of the organization Finally, once you have so many wins under your belt, the rest of the Organization will see the success, and want it too.  Agile ideas make sense, and once the One Team overcomes the hurdles and makes the investment in making Agile successful they become the rallying force that the rest of the organization wants to be part of.  It is not an easy war to win, and there will be many casualties along the way; from overcoming old ways of thinking and doing things to embracing new tools and expectations around how work moves through the organization.  But, by following these simple strategies you can win your war on Agile too! By arming yourself with the right tools and mindset, you too can win the Agile war. Viva La Revolution!  We provide Agile training, to check out the schedule click here  
How to Spark an Agile Revolution: 5 Steps to Win the War

How to Spark an Agile Revolution: 5 Steps to Win the War

Elizabeth Volini
A year and a half ago, if projects were our battles, my company was on the losing side.  The battleground of the IT project portfolio at our Company was a mess — ineffective communication, ...
Continue reading

Five Common Mistakes in Agile

With the increasing popularity of Agile, the mistakes and misconceptions associated with it are also increasing. So, we have put together a list of the common mistakes made while integrating Agile into routine work processes to provide you with an awareness to avoid them to get the best Agile environment for your projects to be successful.  1) Expecting the Scrum Master to be the Project Manager The most common mistake made in Agile is assuming that a Scrum Master is the same as a project manager or a lead developer. While none of these is correct, a scrum master is a role we haven’t seen before. His role is to coach as well as facilitate his team and not manage the team. He provides guidance and advice to his team as well as the product owner on matters regarding the scrum framework.   2) Daily Scrum doesn’t make you Agile Holding daily scrum meetings just for the sake of it isn’t enough to be Agile. To get the most out of the daily scrums, it is vital to stick to its core principles, however difficult they might seem. The basic purpose of daily scrums is for the team to review their progress as well as plan their steps towards Sprint Goal. These meetings also enable the team to identify the obstacles they find on the way and deal with them. It helps in team communication and planning for the Sprint to progress smoothly. However, Scrum alone doesn’t make you Agile, it just facilitates the process.  3) A huge Scrum Team Another mistake in Agile is thinking that you need a huge team to reach the Sprint Goals. On the contrary, an ideal Scrum team is a small and dedicated unit working closely to achieve the goals while keeping itself organized. So, go for a team that is easily manageable and works closely to reach the Sprint Goals instead of having a huge and unorganized team. 4) Thinking Documentation isn’t needed in Scrum The Agile manifesto makes it clear that it values complete functionality rather than documentation, but it doesn’t mean that you don’t have to document anything at all. Before Agile, you had to document each and everything ranging from requirements, to technical specifications to test plans and what not. While with Agile, you just have to document what is extremely valuable for you, for instance, your architecture and source code. So, while deciding what to document, keep the principle of Agile in mind and choose the ones that are useful for the product in some way and need to be written down. 5) Wrong Product Backlog Getting the product backlog wrong can set the whole development of the product off course. This is a common mistake made in Agile. Pay special attention to the initial requirement gathering phase to develop a strong ground for the following phases. For instance, if you are using the User Stories, get them written by the person who is closest to the customers, which would most likely be the product owner.  Try to avoid these common mistakes while integrating Agile to your daily working practices, in order to achieve the best outcomes for each sprint progress. If you are making one of these mistakes already, rectify it to obtain better results.  
Five Common Mistakes in Agile

Five Common Mistakes in Agile

Wasim Irshad
With the increasing popularity of Agile, the mistakes and misconceptions associated with it are also increasing. So, we have put together a list of the common mistakes made while integrating Agile int...
Continue reading

DevOps, Digital & Cloud

In the modern world, the time available to produce new software, develop new products or to release new updates of existing solutions is reducing rapidly. This has resulted in IT services or product development organizations to be more responsive to change and thereby assisting business entities to be more receptive to change as well. The Devops philosophy was born from this need to create a way of working that would enable a more agile and responsive organization. An effective DevOps operation helps reduce the time between concept and cash. In other words, it shortens the time required to create value from new or innovative solution ideas. Good engineering practices centered on good DevOps practices help organizations meet these demands. If above sounds familiar, that is purely because these are also the key drivers behind any organization’s cloud strategy. In addition to time constraints, the modern day IT organizations face budget constraints and financial or non-financial resource constraints. This creates a need for a more flexible hardware environment, in which computational power can be ‘spun up’ in response to operational, development or testing demands and then spun down again when no longer needed. High valued resources can thus be saved through on-demand meticulous planning and utilization of such assets. Amazon Web Services (AWS) is subsidiary of Amazon.com that provides on-demand cloud computing platforms for individuals, organizations and governments. It is a very secure cloud services platform with high computational power, massive and scalable database storage, bandwidth, content publishing and delivery platform with monitoring support. AWS cloud platforms provide pay-as-you go features to organizations thus allowing them to customize the use of cloud resources as per their requirement. This provides organizations the flexibility to select and utilize resources as per their technical, financial and management capabilities. The DevOps philosophy has a symbiotic relationship with cloud-enabled solutions. A cloud environment, whether private or increasingly public is an essential feature of Devops. An agile approach to development requires an agile IT infrastructure to deliver the responsive services that the organization demands. Thus AWS cloud management capability is an essential skill organizations would look to develop and utilize in delivering high valued products fast. On the other hand, a cloud strategy will often not deliver the benefits outlined in its original use case in scenarios where DevOps is not used. Organizations often find that the cost savings promised by a utility model of renting computational power when it is needed often disappear in the face of traditional development schedules and delays. DevOps multiplies the value of the cloud and vice versa. A well-defined DevOps practice with a well laid cloud services platform will enable organizations to quickly get servers up and running. It will enable them to deploy secure backup or failover cluster servers to rely on in case of a disaster. The applications can be securely and quickly be deployed to cloud environments with a fully automated process through DevOps. In conclusion, DevOps and SysOps are here to stay. May it be web or mobile and in deploying on any device or platform, using any architecture, the possibilities for high value products is endless. So, it is up to organizations to use these wisely. We provide Devops training, to check out the schedule click here  
DevOps, Digital & Cloud

DevOps, Digital & Cloud

Rumesh Wijetunge
In the modern world, the time available to produce new software, develop new products or to release new updates of existing solutions is reducing rapidly. This has resulted in IT services or product d...
Continue reading

10 Serious Business Analytics Mistakes You Should Avoid

It’s been quite long since the term ‘Business Analytics’ was coined, but businesses are still unable to deal with it effectively. “Business Analytics basically refers to the thorough investigation of a business’s past performance with the utilization of advanced technologies, skills, applications, tools, and practices in order to identify the blocks of improvement.” It often includes quantitative, statistical, explanatory, predictive as well as fact-based data and analysis that help in better decision-making. Business Analytics is basically helping businesses to makes sense out of their data by answering the following set of questions efficiently:  Why are certain things happening?  What will happen in near future?  What will push these things? and,  What things led to the current situation? In addition to the above mentioned, there are many other purposes that Business Analytics report serves for every business including:  It helps to make a sound business decision that influences overall functioning in the organization.  It enhances the level of understanding towards available data resources to improve operational efficiency at different levels.  It helps to process information in a meaningful manner in order to offer competitive benefits to the organization.  It helps to convert the collected business data into valuable information block that foster informed decision making. Even after the evolution of advanced tools to conduct analysis precisely, there are certain mistakes that analysts or managers do in analyzing overall business performance, regardless of the number of years they have spent in their profession. This post contains the extract of such common mistakes and has listed 10 serious Business Analytics mistakes that you should avoid at all costs. Let’s have a quick overview-  1) Don’t be Confused about Your Role First and foremost thing you should take care of is your role and responsibilities for the assigned project. With a defined scope of your role, you will know the things you are answerable for. 2) Don’t List Requirement On Your Own Being a Business Analyst, you are not supposed to work on assumptions, especially when it is about business requirements. Make sure you carefully analyze the business requirements for the upcoming project by discussing them with the individual department heads or team leaders. 3) Don’t Hesitate in Raising Queries Don’t be afraid to raise questions. If you do not raise queries, you might feel unable to answer your seniors or stakeholders for problems that may arise in the later phase of the project, just because you couldn’t clarify certain things. 4) Don’t Miss Functional Requirements  Once you are sorted with the business requirements, it’s time to trace them in test cases with the functional requirements and development practices for making the entire process smooth for not only you but everyone else. 5) Don’t Forget to Get Feedback Whether you are about to float any report, important document, or a PowerPoint presentation, make sure you seek feedback from the concerned persons including project managers. This will help you improve at personal as well as professional level. 6) Don’t Ever Ignore the Stakeholders Ignoring your stakeholders for any reason, especially at your level may invite trouble. Follow a proactive approach through a one-on-one meeting to take their opinions and leave no stone for possibilities or potential risks unturned. 7) Don’t Be In Hurry to Complete Tasks Don’t work on anything just for the sake of completing. Understand the criticality of your role for your business and act in a responsible way. Being too speedy about things could turn out to be a deal breaker. 8) Don’t Let Excuses Kill Your Productivity If there’s something that is interfering with your productivity, you should take a break or convey it directly to your manager, rather than coming up with excuses and causing an unnecessary delay in business processes. 9) Don’t Mix Up Stated Needs With Real Ones After conducting different processes including one-on-one sessions, anonymous surveys, and group discussions, you will get a long list of needs from the employee (or real-time users). Your responsibility is to sort out the real needs from that list through your keen investigation. [Remember: Anything that we think we need is not necessarily something we actually need. There are other solutions around to work upon] 10) Don’t Believe in Rhetorical Statements Gone is the time when rhetorical statements were used to cover reports or reflect outcomes. Now, you should have clear and concise statistical data in hand to prove the credibility of the resources, tools, or processes involved in a particular project. 11) Don’t Refrain from Quantifying Results Last but not the least, when it comes to showcasing the estimated results in terms of ROI, let the numbers express the whole story to the concerned managers, CEOs, stakeholders. If your report says that customer complaints reduced by 40%, they will be able to make sense out of it.  If you are a Business Analyst too, you can also create a checklist accordingly to avoid these fallouts and give your best for every project assigned. Are you ready to be a smart business analytics professional? We provide Certified Business Analysts Professional training, to check out the schedule click here  
10 Serious Business Analytics Mistakes You Should Avoid

10 Serious Business Analytics Mistakes You Should Avoid

Priyanka Arora
It’s been quite long since the term ‘Business Analytics’ was coined, but businesses are still unable to deal with it effectively. “Business Analytics basically refers to the...
Continue reading

One Simple Hack to do Business Case Writing like a Pro

Whether you are a start-up or well-settled business establishment, there is one common phase you have to go through before starting out any project i.e. Business Case Writing. It is an immensely important step to be taken in the very early stages of a project that highlights all the necessary resources to be involved, their cost and management, backup resources and most importantly the timeline. Also, the expected benefits and overall influence on business make a part of an effective business case. “A business case captures the reasoning for initiating a project or task.” This is how Wikipedia says it crisp and clear about the business case. It is usually proposed as a well-drafted document, but nowadays, it is often proposed as presentations. An impressive business case is the one that includes both quantifiable and non-quantifiable aspects of a project in absolute terms.  Why Writing A Business Case Is Important? A business case holds significance because it helps to evaluate the value of a project and its respective returns for a company in a concise manner. Moreover, it outlines the performance indicators for the entire workforce involved in a particular project. This further helps decision-making bodies to recognize individual potential while pushing their limits to a whole new level with extended responsibilities on the table. With a well-defined business case, it becomes quite easy to have an idea about:  Awaiting business opportunities (while some refer them as problems)  Positive outcomes   Risks or setbacks   Total costs to be incurred (including all the investments and appraisals)  Turn Around Time  Backups or failure-escapes, and  The undefined capability of the workforce to deliver expected results. A document so critical obviously needs great precision to work with. It won’t be an easy task. And, let’s face it, sometimes even experienced professionals fail to do business case writing aptly.  This blog will reveal that one simple hack – which will help you through this significant phase like a pro. The hack is to break down the entire case into seven important questions including: Q1: Why the project worth making an investment? You should gather enough details and information about the project, and present it in simple and easy-to-comprehend language so that every other member of the decision-making committee can understand why you are proposing that project. Q2: What objective will the project serve to the organization? With anything proposed in a business establishment, there is a need to brief the future state that a particular project or step is going to bring. Make sure you define the project objective clearly to avoid any hassles in later phases. Q3: How the project will improve the current situation of your organization? Next, in the queue comes a compelling argument about the benefits of the project. Make your draft more convincing using graphical representations showing the current scenario and the improvements everyone can expect in the near future. Q4: What are the different possibilities to execute the project? Now that everyone is convinced about the outcomes of the project, the next question lies afore you is HOW. You have to give a detailed presentation underlining all the possible options that can be looked upon for successful completion of the project. Q5: What are the parameters to measure the success ratio? Once a project is started, it becomes pivotal to define certain parameters to help measuring the success rate. This helps you to know whether you are moving ahead in right direction or there is a need to switch to some other alternative to reach paramount. Q6: What external resources will be required for project success? It is often a case that your organization may not have adequate resources required for the project execution. Be sure you have briefed all such external resources well in advance so to ensure their availability at the time of need. Q7: How much time will be required and what next it triggers? Last but not the least; you have to come up with a specified range of time for your project. As this helps in distribution of resources and making cost estimations for the additional resources required.  Additionally, you should define the next steps once the project is completed. After all, growth is a continuous process. You just cannot stop after setting just one milestone. Keep moving, keep setting new milestones. Once you will be able to answer these seven questions in your with complete consideration, Congratulations! You did your business case writing task well. Here're some best tips to improve business writing skills  
One Simple Hack to do Business Case Writing like a Pro

One Simple Hack to do Business Case Writing like a Pro

Priyanka Arora
Whether you are a start-up or well-settled business establishment, there is one common phase you have to go through before starting out any project i.e. Business Case Writing. It is an immensely im...
Continue reading

Making DevOps Applicable For You

In summary, DevOps is a philosophy of software development that focuses on meeting business requirements quickly and efficiently. It helps shorten time to value and in so doing helps create a more responsive organization. It multiplies the value from investments in cloud and encourages automation of key processes for better outcomes. All of which makes it highly suitable to cost constrained organizations that must deliver improvements to their current services and products while taking advantage of the opportunities presented by new digital and data-driven technologies. However, the advantages of the DevOps helping for organizations in large scale.  The long-term cost reductions are substantial, but the initial investment can be high. Although automation delivers a strong return on initial investment of time and resources, it does take longer to complete this initial automation of a task that it does to perform the same task manually. Maintaining the DevOps approach will also require specific technical skills to be build up, managed and retained by the implementation organization as well as the client organization. So, how do you make sure that the adoption of the DevOps approach works for your organization? The following can be those critical factors. Senior management buy-in As with all change projects, success is in part dependent on having committed leaders at senior leadership levels; in this case the CIO, CTO or the chief architect (and even the enterprise architect of the client organization) who can deliver technical and cultural changes. They are responsible for making sure the focus remains on breaking down the barriers between development and operations and ensuring the approach is designed around this core principle. They need to make sure that close collaboration between developers, system operators and testers is maintained and that open lines of communication with business users and service commissioners remain intact. Understand the demands of digital transformation It is important to understand the demands of digital transformation and balance it with the rigour of ITIL. At present, only about 5% of services of organizations are driven by technologies that are digital by design. Applying DevOps to these technologies is relatively straightforward. But mission-critical platforms on physical or virtual servers are a different question altogether.  An iterative approach to migrating these applications to the cloud, taking small steps to transformation and applying DevOps one step at a time requires not just digital skills but the depth of understanding residing in experienced IT managers. Need for security, compliance and governance It is important to ensure that testing and security are built into the automated processes of the implementing organization. Those processes must stay true to ITIL standards for security testing and compliance checking. Even at this pace software can only be put into production when it has no vulnerabilities that can corrupt sensitive information.  DevOps does not replace the need for quality assurance, software testing or data validation before and after a software release. Hence it is important to get the QA practices with regards to automated testing for security, performance and code check-ins and check-outs in top shape. Work with the right people Some IT services service providers are great at automation or at building digital services. Bringing them together is the key. This means that IT practitioners who already have wide experience of delivering systems under the DevOps umbrella and are prepared to share best practice and ensure effective knowledge transfer are a key part of the team. So are leaders with expertise in automating business and management processes and have a well defined and tested set of tools to support their work.  It is important for client organizations to look for service providers with real, in-depth experience of open technologies, domain expertise and cloud-based solutions and with the necessary hands-on experience in designing, building, migrating, supporting and operating scalable and robust systems for their customers.  
Making DevOps Applicable For You

Making DevOps Applicable For You

Rumesh Wijetunge
In summary, DevOps is a philosophy of software development that focuses on meeting business requirements quickly and efficiently. It helps shorten time to value and in so doing helps create a more res...
Continue reading

Best ways to implement Leading SAFe 4.5 in organizations

SAFe stands for Scaled Agile Framework. This framework is mostly used by the corporate bodies which need to scale from smaller organizations to larger ones. So SAFe is also known as an enterprise-scale development methodology. This framework was coined by Dean Leffingwell. It is an ‘information base’ which is freely available, and allows you to apply Lean-Agile practices at an organization level.   Scaled Agile Framework (SAFe) is referred as the Agile framework for software development. It renders an ease of operation for the development team. SAFe 4.5 is the most updated version introduced to match the needs of the organizations. This version consists of some new features as follows:  Fastest delivery with scalable DevOps and Continuous delivery  Quick testing using the Lean Startup cycle and User Experience (UX)  Improved Portfolio performance with Lean Portfolio Management (LPM) and Lean Budgets Additionally, SAFe 4.5 allows organizations to transform from the traditional approach to Lean-Agile methodology with the new Implementation Roadmap. Implementation Roadmap of SAFe 4.5 is a guide for the organizations. Reasons to switch to SAFe 4.5: ●  The updated version of SAFe 4.5 supports the range from simplest to the most critical development environment. SAFe 4.5 is able to mould according to the organizational needs. SAFe has four new   configurations as follows:  1. Essential SAFe - an initial phase which starts just after realizing the benefits. 2. Portfolio SAFe - adds portfolio level, strategy and investment funding, guidance on Agile programs, and Lean governance as a scenario. 3. Large Solution SAFe - for building large systems that involve Agile Release Trains and Suppliers 4. Full SAFe - for the largest firms those are seeking the benefits of the Lean-Agile enterprise.   ● SAFe 4.5 works by integrating Lean Startup Cycle and Lean UX, which creates an environment to form Minimum Viable Product (MVP). It fosters quick innovation. ● SAFe 4.5 has concentrated on the feature of rapid delivery using the techniques like Scalable DevOps and Continuous Delivery Pipeline. ● SAFe 4.5 has provided a guide in the form of a 12 article series, given a name as ‘SAFe Implementation Roadmap’. Based on the Change Management technique in the organization, the roadmap       guides on the critical steps that an organization can take to achieve long term goals.  ●  SAFe 4.5 is completely backward compatible. In SAFe 4.5, you just need to adopt the advanced principles, keeping old versions in place.                                                                                                  How is SAFe 4.5 Implemented? SAFe Implementation Roadmap provides guidance to the organizations in the form of a twelve-article series which describes effective strategies and a set of activities to implement SAFe at an organizational level. Let me illustrate the 12-article series below-   Reaching the tipping point.  Train Lean-Agile change agents  Train Executives, Managers and Leaders  Create a Lean-Agile Centre of Excellence  Identify Value streams and ART’s  Create the Implementation plan  Prepare for ART Launch   Train Teams and Launch ART   Coach ART Execution   Launch More ARTs and Value Streams  Extend to the Portfolio   Sustain and Improve SAFe is a pivotal framework as it helps to achieve business benefits at an organizational level. In order to understand the outcomes of Leading SAFe implementation, organizations must embrace and understand the Lean-Agile principles. Based on the Change Management strategies in the organization, the SAFe Implementation Roadmap guides on the critical steps that an organization can follow to achieve long term goals.   
Best ways to implement Leading SAFe 4.5 in organizations

Best ways to implement Leading SAFe 4.5 in organizations

KnowledgeHut Editor
SAFe stands for Scaled Agile Framework. This framework is mostly used by the corporate bodies which need to scale from smaller organizations to larger ones. So SAFe is also known as an enterprise-scal...
Continue reading

Embracing Lean & Agile Values in SAFe® 4.5

The basic premise to develop the Scaled Agile Framework is to enable organizations to scale up agile development practices to enterprise scale. One of the key constructs upon which SAFe is built upon is the ‘Lean-Agile Mindset’. This is defined as ‘the combination of beliefs, assumptions and actions of SAFe leaders and practitioners who embrace the concepts of the Agile Manifesto & Lean Thinking’. Agile provides the thinking and mindset related to achieving high levels of efficiency, productivity, collaboration, team motivation and quality. However, the agile principles work well in the delivery of smaller, less complex solutions rather than applying it to enterprise wide solution implementations. Scaling agile framework requires a wider array of knowledge, skills, leadership and a change in mindset to adopt and apply lean agile principles. Aspects of Lean-Agile The lean-agile mindset in SAFe is built upon 2 main constructs. These provide the knowledge and help drive the skills required to create and manage the culture, organizational structure, leadership and management approach required to drive organizations adopting SAFe and to allow them business objectives. The two key aspects of lean-agile mindset are- Lean Thinking which is primarily defined through SAFe’s ‘House of Lean’ which was derived from Lean manufacturing inspired by Toyota’s ‘Houses of Lean’. This was then applied to software products and solutions development. The end goal of any project, however big or small is to deliver value to its stakeholders. The roof of the house is thus represented by delivering value in the shortest possible time ensuring maximum possible quality.  Some of the principal pillars hold up the house of lean. They represent respect for people & culture, flow, innovation and relentless improvement to support the end goal of value delivery. Work in any project is carried out by people and thus the respect for people and culture becomes utmost important for any team. Team together face challenges, learn new techniques and skills, solve problems and move forward and make improvements to projects and processes. Managers generally challenge the status quo and empower people to achieve more. The motivator behind this behavior is the team culture. Organizations and leaders must first embrace this culture and then try to instill that in their staff and even beyond organization’s boundaries towards other external stakeholders. It is important to note that culture cannot be changed overnight but can only be molded over time. The 2nd pillar of flow refers to a continuous flow of work to support incremental delivery of value. One main objective of an agile project is to make small increments to the solution over time and to keep on adding business value through continuous delivery. This must also be done while improving on engineering practices, improvements to solution quality and project governance through proper tracking. Visualizing the flow is an important aspect in Agile and in Lean. We all know about the Scrum and Kanban boards in agile projects and how they created visibility of project progress. This same concept must be scaled up with more visibility of tasks, components, modules and even systems with emphasis given to identifying and reducing non-value adding activities. Continuous delivery through DevOps and SysOps through the automation of software engineering, QA and deployment practices thus becomes a pivotal capability for any organization. Innovation is a key pillar in the house of lean and is placed in the middle. No team or organization can be improve or continuously deliver value without innovation. Thus SAFe encourages team to challenge the norm, continuously explore new frontiers, be creative and move out of their comfort zones. Innovation and Planning sprints are thus a key component in the SAFe hierarchy. The 4th pillar is to relentlessly improve the product and the processes. Organizations are expected to be learning through review and retrospectives.  The foundation of the house of lean is Leadership. Leadership plays a key enabler role for team success and successful adoption and implementation of lean-agile approach depends with the organization’s executive leadership, managers and team leads. Embracing Agility is the 2nd construct in lean-agile. SAFe is built upon skills, capabilities and aptitude of teams and their leaders. The agile manifesto for software development describes the principles and practices related to carrying out project activities in an agile manner.  The agile manifesto describes 4 values and 12 principles. Agile values motivates teams to focus more on-   Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan Agile motivates teams to be self-organizing and self-healing, to face problems as one single unit, collaborate and solve problems and to continuously build something that can be demonstrated to customers. The objective is to get feedback as soon as possible and make necessary changes as required. The requirement in SAFe is to apply these same set of values at team level as well as among multiple or large scale teams. SAFe provides the basis for organizations to plan and build enterprise class applications and that too in an agile manner. It provides organizations with the processes and principles required to successfully apply these practices. The lean-agile values provides the platform for organizations to build their practices on and provides a organized approach to manage and thrive in chaos.  
Embracing Lean & Agile Values in SAFe® 4.5

Embracing Lean & Agile Values in SAFe® 4.5

Rumesh Wijetunge
The basic premise to develop the Scaled Agile Framework is to enable organizations to scale up agile development practices to enterprise scale. One of the key constructs upon which SAFe is built upon ...
Continue reading

Introduction to Scaled Agile Framework (SAFe®)

Implementation of software solutions vary based on complexity and magnitude. Not all implementations are simple and straightforward. Software solution implementations of enterprise scale require more rigorous processes and streamlined practices to allow businesses to address challenges posed during such engagements. Businesses are also required to take up such challenging implementations while operating in challenging business environments which forces them to implement solutions in the shortest sustainable lead time. Best practices for scaled agile framework tells you principles which can benefit the organisation As we all know, the change-driven approaches of Agile project management came into being to address the problems in traditional long running plan-driven software projects. But, Agile projects were traditionally more suitable for smaller projects that required six to eight team members. So, the need for a process to deliver large scale projects using Agile methodologies increased over the last few years. The scaled agile framework provided the much needed guidance for the same. Reason for SAFe® The primary motivation for SAFe was to allow for collaboration, synchronization and coordinated delivery of solutions developed by multiple Agile teams. SAFe is a framework that can be scaled up or down as per the requirements of the organization. Thus, SAFe supports small-scale solution implementations which require 50 to 125 team members as well as complex, cross departmental and even cross-organizational solution implementations that require thousands and ten thousands of team members. How does SAFe work? It is fascinating to understand how SAFe facilitates scaling of this magnitude? SAFe framework describes roles, responsibilities, artifacts and activities that are required to develop and deploy software solutions Lean-Agile software implementation principles. SAFe principles are developed using 3 main bodies of knowledge. They are as depicted in the diagram below.  Agile development embraces change where cross-functional, self-organizing and self-healing teams develop software in an iterative and incremental manner using small bursts called sprints.  “Systems thinking” motivate team members to consider each and every element that are within the context as a whole. For example the business context for which a solution is being developed may involve factors internal to a business such as data, systems, technology, resources (financial and non-financial) as well as factors which are external such as competitors, government and regulatory bodies, suppliers and distributors, financial institutions etc. which may all impose constraints on the solution.  One of the key principles in Agile methodologies involves lean principles which is to minimize waste or non-value adding activities and to increase the probability and impact of value-adding activities.  Common questions, which SAFe addresses   SAFe was developed to address the following industry wide questions. How can organizations scale agile practices starting from small agile project teams, to larger programs, to business unit or enterprise wide programs or portfolios and even to cross-organizational mega projects? How can teams of scale be organized around continuous delivery of value? How can teams of such magnitude collaborate effectively avoiding delays and bureaucracy evident in such large scale projects if run as traditional projects? How can dependencies between multiple teams be managed? How can an environment that fosters collaboration, continuous improvement and innovation be created and sustained? How can culture be molded to motivate team members to make mistakes and learn from them? How can the team measure success of new working methods followed and how can they make it more efficient? SAFe provides a well-defined set of values, principles and practices which can be adopted enterprise-wide to better address these questions above. In my upcoming articles I will discuss about different configurations of SAFe with details on how different roles, systems, practices and values contributes towards continuously delivering value through the agile release train.  
Introduction to Scaled Agile Framework (SAFe®)

Introduction to Scaled Agile Framework (SAFe®)

Rumesh Wijetunge
Implementation of software solutions vary based on complexity and magnitude. Not all implementations are simple and straightforward. Software solution implementations of enterprise scale require more ...
Continue reading

SUBSCRIBE TO OUR BLOG