rachaelwilterdink - Tumblr blog

rachaelwilterdink · 2 months

Text

How to Earn IIBA®’s CBAP® Certification

I was recently chatting with another Business Analyst colleague, who was interested in learning more about certification. I figured I had already written a blog about this, but when I searched my own site, I discovered that wrote a blog about the benefits of certification, but I somehow missed writing about my actual experience in earning the CBAP® designation from the International Institute of Business Analysis® (which is one of the greatest accomplishments of my professional life). So, to remedy this gap, here’s my guide to getting certified as a Business Analysis Professional!

Join the IIBA®

The best thing any Business Analyst can do to move their career forward is to become a member of the IIBA®. This is the organizing body of the profession, established in 2003, and the benefits of being a member are incredible. I recently wrote a blog citing my Top 10 membership benefits, so be sure to check it out.

As it specifically relates to certification, as a member, you have access to a free copy of the Guide to the Business Analysis Book of Knowledge® (BABOK®), which is the main reference material for the exam. As a member, you also get to take the exam at a discounted rate. Subsequent recertification fees are also reduced for members.

Review the CBAP® Handbook

The next step is for you to download the CBAP® Handbook from the IIBA®’s website. This is your step-by-step guide to the process of applying for and taking the exam. Interestingly, it looks like the requirements have changed since I sat for the CBAP® (originally earned in 2015). When I took the exam, the minimum required education was a high school diploma. Previously, (if I remember correctly) if you had a bachelor’s degree, you needed half the number of experience hours. Now, the CBAP® handbook doesn’t even reference educational requirements, and the experience requirements appear to be the same for all candidates.

Do the Work and Document Your Experience

To be eligible to sit the CBAP® exam, the IIBA® expects you to have at least five years of experience, with 7,500 hours of work history within the past 10 years. So, don’t even think about going for the CBAP® if you haven’t put in the time. There are other levels of certifications you may still be qualified for that would be worthwhile considering while get the necessary experience hours (ECBA™ and CCBA®). I didn’t do either of these certifications, but the prep class I took used the same materials and was the same course for people preparing for either the CCBA® or CBAP®.

Get 35 Professional Development Hours

Another requirement for being eligible for the exam is earning 35 professional development hours. There are plenty of prep courses and boot camps out there that will get you the hours you need and prepare you for the exam at the same time. That’s what I did, which can be pricey (fortunately, many companies will pay for this), but it’s not the only path. Check out IIBA®’s list of options that can help you get the hours you need. Keep in mind that you have to earn these credits before you apply!

Line up Two References

A unique requirement of the CBAP® is having two professional references who vouch for you. The IIBA® is specific about who you can use for a reference – it has to be people who have known you at least six months, and acted as your supervisor/career manager, or is an internal or external client you have worked with, or someone who already has either the CCBA® or CBAP®. So, nope - your peers and friends won’t suffice as your references.

Fill Out the Application

I always tell anyone who asks me that the application process for the CBAP® is half the battle when it comes to earning this designation. You should feel good that you didn’t have to do this “back in the day” when it was a paper application. The online application has also improved over the years, too, so it’s much easier to complete than in the past. All of that said, it’s still a daunting task. To qualify for the exam, you must align your experience with the knowledge areas of the BABOK® and have a minimum of 900 of those hours completed within four of the six knowledge areas (for a total of at least 3,600 of the total 7,500 hours required). It’s a lot. You must remember every job you’ve ever had, every project you’ve ever worked on, and what business analysis work you did on each. It’s intense and time-consuming. You’re extremely lucky if you have only worked at one company and they happen to have a time-tracking system with your work recorded – in this case, you can just do a data dump that will speed things up dramatically. Most people aren’t that lucky, though.

Pay the Application Fee and Submit

Another unique requirement from the IIBA® is that you must pay even to have your application considered. As of this writing, the cost in USD to apply is $145. Also keep in mind that it’s non-refundable. If approved, you then have three attempts within one year from your application’s approval. You get two re-takes, but you must pay for each attempt. And, if your application lapses, you get to start all over again! So, if you get this far, don’t let it be for nothing!

If You are Approved, Pick a Target Date

It can take a few days (or more) to get an answer on whether your application is approved. This is a seriously stressful time – trust me. When I went through this, it seemed like there was great variability in how long it took to hear back. I’m guessing it’s more automated now, so I would anticipate most people would get a response quickly. Hopefully, you’ll get the message that your application has been approved, and the email will provide you with instructions for the next steps. Just getting approved to take the exam is a huge accomplishment, in my book, so have your first mini celebration when you know you’ve passed the first step!

Then, choose a target date for taking the exam that is less than a year from the date of your approval. Having a date on the calendar will give you a sense of urgency and give you a starting point to work backward from when building your study plan.

What to do if you are Not Approved

I didn’t experience this personally, but I wouldn’t be surprised if this happened often. Like I said before, the application is extremely rigorous and it’s easy to miss things. Don’t be discouraged if you do get rejected – I assume the IIBA® will tell you what was missing or wrong, and then you can remedy the problem and re-apply. But, again, you’ll have to pay for another application, so you’d be better off double-checking your original application to make sure you nailed it.

Create your Study Plan

With a target date picked, it’s easy to lay out your study plan on a calendar. Everyone has their own best way of learning, so hopefully you know what yours is, and your study plan will reflect the activities that work best for you. Attend a Boot Camp I was fortunate enough to have my company’s support and they sent me to a preparation boot camp. Not only did this earn me the necessary 35 Professional Development hours, but it also gave me a good guide to the contents of the BABOK® and tips on how to pass the test. This was a great supplementary material that I used in my studies. Absorb the BABOK® However, my primary focus was going chapter by chapter of the BABOK®, with more attention on the knowledge areas, of course. I also didn’t follow the order of the materials in the BABOK® because it’s not meant to be a sequential process – I decided what made most logical sense to me and proceeded accordingly. As I was going through each part of the BABOK®, I created a question/answer spreadsheet that I uploaded to a study site called Cram.com, which made it easy (and fun) to drill. Buy a Prep Book There are a couple of good prep books that different business analysis experts have published. I would pick one of these up (be sure to read other readers’ feedback before buying). Some also come with subscriptions to sites with practice exams, flashcards for drilling, etc. Books like these can help make the materials of the BABOK® more accessible. Take Practice Exams As part of my boot camp course, I also had access to Watermark Learning’s practice exam and used that heavily to gauge my weak areas so I would know where to focus my studies, along with my readiness and confidence to take the actual test. This company has since been acquired, so I'm not certain whether their online exam simulation is still available. I also found other sample of practice exams and worked those into my plan.

Study Every Day

Once you have your plan in place and your study materials, the best thing you can do is study every day. Yes, you read that right – study every single day. This is not easy stuff to absorb, and the best way to do it (besides being an active practitioner) is to drill it daily. If you try to cram for an exam like this, it’s doubtful that you’ll pass, and you’ll certainly stress yourself out. Stick to the tortoise and the hare rule – slow and steady wins the race.

Pay for and Schedule the Exam

You may never truly feel “ready” to take an exam like the CBAP®, just because of the sheer volume of knowledge and experience you must have. But that’s why having a date (and a deadline – remember you must sit the exam within a year of your approval) will force you to do it anyway. When you decide to schedule the test, dig up your approval email and follow the instructions. Proctored Online Taking the test online wasn’t an option when I earned the CBAP®, but due to the wonders of technology (and maybe COVID), the exam is now available to take online. You will be proctored, which means you will be watched as you take the test, and there are pros and cons to doing it this way. I have taken a few other similar exams, and you may run into technical issues (which I did), your environment must be perfectly spotless, and you’ve got to have a rock-solid internet connection. If you’re worried about any of these things going wrong, you might be better off going to a testing center. When things go wrong (and they always can), it will increase your stress level and may cause you to bomb the exam. In-person Testing Center Although taking the exam at home might seem easier, a test center has its drawbacks, too. When you arrive, they treat you like a criminal – you must get “wanded,” empty your pockets, take off all your jewelry and such, and put everything in a locker. It’s a little bit like being in a library in a private cubicle, but with cameras and people watching you. So, stressful doesn’t even begin to describe it. But, if you go this route, at least you can’t be blamed if something goes wrong with the technology. Another nice thing is that when you pass, you get a certificate immediately.

Take the Exam and Pass

The actual process of taking the exam is where the rubber meets the road. A lot of trainers will recommend you use a single allowed piece of paper or whiteboard to do a brain dump. I didn’t do this because I think this is a tool used more for crammers than people who took the time to study slowly and steadily. Answer All the Questions and Guess if you Must A top tip I remember from my boot camp is that it’s best to answer all the questions, even if you’re not sure about the answer. If you skip a question, you have zero chance of getting it right; if you make your best educated guess, you at least have some chance. Flag Questions to Come Back to Regardless of whether you’re taking the test online or in a center, you can flag questions you’re unsure about so you can come back to them later. Use this feature. You don’t want to waste too much time on any one question, and if you flag a question, you can come back to it if you have time. The system makes it easy to go right back to any questions you flagged. Your First Instinct is Usually the Best Choice Another tip I recall from my boot camp is that your first instinct is usually the best choice, so it’s best not to overthink things. If you change an answer, chances are that you’re changing it to a wrong choice, so it’s best to go with your gut. Watch the Clock and Pace Yourself It is best to be aware of how much time you have remaining – the system usually displays a ticker showing you how much time is left. Try to aim for having a certain number of questions answered by a certain time, and speed up or slow down accordingly. Review if You Have Time If you get through all the questions and have adequate time remaining, go back through all the questions. Make sure you didn’t miss any. Guess on ones you aren’t sure of, using your best educated guess. Only change an answer if you are 100% certain you should. Submit! When you are done, hit the “Submit” button (or whatever it’s called). Don’t be alarmed if you receive a survey before you see your test result – this is incredibly annoying, but it ensures you fill the stupid thing out. It might take a few seconds, but after the system has processed your exam, if you did well, you’ll see a congratulations message. I don’t remember seeing any other words on the screen than “Congratulations!” Then, take a deep breath – you did it!

Celebrate!

Don’t forget to celebrate and share the news! Earning the CBAP® is no small feat, and it shows that you are among the elite in the profession.

What to do if you don’t Pass

I know plenty of people who didn’t pass on the first attempt. If this happens to you, don’t despair – there’s a reason this certification is so well-respected and difficult to achieve. You can take the test again, and now that you know what the experience is like, you know better what to expect so you can be prepared. You have up to two more attempts, so study again and focus on your weak areas. Don’t let a failed attempt stop you from moving forward – you can do this!

Good Luck!

I hope this guide is useful in your own journey toward earning the CBAP® designation. It’s not easy, but it’s well worth the effort. If anyone else has additional tips, please let me know in the comments below! Read the full article

#analysis #business #cbap #Certification #certified #IIBA #profession

0 notes

rachaelwilterdink · 3 months

Text

5 Reasons Why I love Being a Business Analyst

I have been a Business Analyst for most of my adult professional career. I fell into the role somewhat by chance (through a merger and acquisition), but it was one of the best things that ever happened to me. There are so many things that I love about being a Business Analyst that it’s hard to narrow it down to just a few, but here we go!

Building Relationships

The business of Business Analysis at its core is all about people. A Business Analyst is a pivotal role that requires being able to navigate all levels of an organization, in all different realms. As a result, the heart of being a BA is building relationships. I can converse with a CEO just as easily as I can talk with someone answering calls at the IT Help Desk. Having this ability has helped me grow my network of connections over the years, and I am grateful for everyone I’ve been able to work with along the way.

Learning New Things

Business Analysis affords the opportunity for continuous learning. The world isn’t static, and everything is constantly changing, from organizational structures, disruptive recent technologies and innovations, government regulations, new ways of working, and the list goes on and on. There is always something new to learn, and as a BA, I always want to be ready for what’s next. This means staying up to speed on what’s happening and learning whatever I need to know to get the job done.

Variety is the Spice of Life

Another thing I especially love about Business Analysis is the variety. No two projects or initiatives are ever the same, nor is every day. In fact, every day in the life of a BA can look vastly different. When I was a consultant, this was even more true. Every new client usually represented a new industry or market for me, and I got to explore many worlds I never would have been exposed to otherwise (PM if you want to hear some amazing stories!).

Delighting Stakeholders

Seeing the joy on a stakeholder’ 'faces when we show them what we built for them is one of the best moments in a Business Analyst’s professional experience. When you see bright smiling eyes appreciating the work you’ve done, there’s nothing more rewarding. No paycheck, no bonus – nothing can compare to making people happy and having a measurable impact on their lives.

Helping Others Grow

Another thing I have been able to do as a Business Analyst is to help train, mentor, and grow a newer generation of Business Analysts. While it’s a rewarding profession, being a BA is not an easy job. There is so much to know, and much of it you can only learn through experience. As a seasoned professional, it’s been my pleasure to support other young analysts as they develop into qualified, competent practitioners.

Final Thoughts

In this blog, I covered a few of the things I love about being a Business Analyst. Every analyst has their own journey and experiences, and I am eager to hear what other people enjoy about the profession. If you care to share, please do so in the comments section below! Read the full article

#analysis #ba #bas #business #career #growth #journey #learning #love #mentoring #profession #professionals #stakeholders

0 notes

rachaelwilterdink · 3 months

Text

The Top 10 Best Benefits of IIBA® Membership

I joined the IIBA® a long, long time ago (in a galaxy far, far away – well, maybe not – just kidding). The organization has grown enormously since its inception 21 years ago. As the institute has expanded, so have the benefits it offers its members. I would not have achieved what I have in my career without the knowledge and support of the IIBA®, so it’s with gratitude that I share my favorite Top 10 Best Benefits of IIBA® Membership. Free digital copy of the Business Analysis Book of Knowledge First and foremost, the IIBA® is the publisher of the Guide to the Business Analysis Book of Knowledge®, what I and other Business Analysis call our “BA Bible.” Now in its third major version, the BABOK® is the definitive source of knowledge for practicing the profession of Business Analysis. As a member of the global organization, you have access to a free digital copy of this standard, which is foundational to become a business analysis professional. It's also available in multiple languages.

As an IIBA® member, not only do you have access to the BABOK®, but there are many other digital publications at your disposal, including the Agile Extension (2nd version), Product Ownership Analysis, and others. Online digital library Access to the online digital library is one of the most overlooked and undervalued benefits of IIBA® membership. The cost of membership is worth of every penny even without this perk, but with access to so 11k+ books, this benefit is, well… priceless! You’d be a fool not to take advantage of FREE books!

The library covers so many topics relevant to our profession - everything from agile to leadership, to (God forbid) project management. If you want to learn something new, the IIBA®’s digital library should always be your first stop. You might be surprised at the quality of content you may find. Membership to a local chapter of your choice Recently, the IIBA® introduced a concept they called “harmonization” which merged the global organization with the local chapters. Now, when you become a member of the worldwide institute, you can join any local chapter of your choice. There are local chapters across the globe, and they’re your closest community resource.

Local chapters have boards that you can volunteer to participate in, or if you just choose to be a member, you can enjoy in-person and virtual chapter meetings, study groups, mentoring, and more (depending on each individual chapter’s offerings). Ability to attend ANY chapter’s events, worldwide! When you join the IIBA®, even if you elect to join a specific local chapter, you are still able to attend any chapter’s meetings (whether virtual or in-person). This is a HUGE benefit! If you are certified, you can earn CDUs by attending, and the variety and options of topics are limitless!

I have attended chapter meetings from coast to coast of the United States, and Canada. But that’s just Northern America! The IIBA® is truly a worldwide organization, and if you want to attend a meeting anywhere, you can! Member-only webinars to continue your education and earn CDUs In addition to many webinars that are open to the public, the IIBA® also reserves some of its best speakers and content exclusively for its members. Members-only events provide relevant and timely topics that can help you continue to grow and expand in your own Business Analysis career.

Their calendar is chock-full of engaging opportunities to learn new tools and techniques, along with the opportunity to network with your fellow business analysis professionals from around the world. The IIBA® sends out regular reminders with upcoming topics, so there’s no excuse to miss a chance to learn something new! Reduced cost for certification application, exam, and renewal fees It’s not cheap to pay for a certification, especially ones as respected as those offered by the IIBA®. As a member, you’ll get a discounted rate for all certifications offered, and the savings are substantial! I have three different IIBA® certifications, and I have saved a ton over the years, thanks to my membership.

I should also mention that from time to time, the IIBA® offers even further discounts, whether for a specific certification or for all their offerings (usually toward the end of the calendar year). If you’re looking to get maximum savings, be on the lookout for these special prices. - Online jobs board for both employers and potential employees I haven’t had much need for a job-hunting tool during my career as a Business Analyst, but if you want to go directly to the source, you couldn’t do much better than the job boards that are available as part of your IIBA® membership.

While it’s obviously a third-party service, like the online library, it’s worth the effort if you’re looking to find your next business analysis job. You can create your own profile and rest assured that the job postings are from companies that understand what Business Analysts do! - Competency model to gauge your level of experience An excellent addition to the many other benefits offered by the IIBA®, their competency model can help you figure out where you are in your professional development. Their assessment tool can help you identify your areas of strength and weakness. You’ll know exactly which areas you need to beef up in to grow your career.

As a member, you have access to the competency model as an individual; companies can also license this tool to help their overall Business Analysis practices mature, as well. - Discounts to attend the IIBA®’s global annual conference I would be remiss if I didn’t mention that IIBA® members also get early bird and membership discounts to attend the official annual conference of International Institute of Business Analysis: Building Business Capability (BBC). This is a “can’t-miss” event that brings together the global community of Business Analysis in one place (usually alternating between Florida and Las Vegas, USA).

I have attended this conference more than once, and I can absolutely guarantee that it is some of the best money a company can invest in growing their Business Analysis capabilities. Analysts of any level will learn new skills and techniques and grow their professional networks. - Access to annual Business Analysis Survey Finally, the IIBA® conducts an annual survey on the profession of Business Analysis, and a periodic salary survey. If you want to understand the state of the profession and assess whether you’re fairly compensated for your professional skills and experience, the IIBA® conducts a very thorough survey and analysis of our profession.

As an IIBA® member, you can access the results of the surveys; you can also participate as a contributor. The surveys are extensive, so there is a time commitment to taking a survey, but trust me, it’s well worth your effort.

Final Thoughts

Well, that’s it. Those are my Top 10 Best Benefits of IIBA®Membership. If you’re a member, I’d love to hear what you think. Do you avail yourself of all these benefits? Are there other benefits I neglected to mention that are worthy of note? Let me know in the comments below! Read the full article

#analysis #benefits #business #cbap #IIBA #institute #international #membership #profession

0 notes

rachaelwilterdink · 3 months

Text

20 Myths About Business Analysis

I have been in the profession of Business Analysis for close to 20 years, and during this time I have witnessed many different myths come and go about this role. In today's blog, I break down 20 myths and debunk them. Enjoy! To be a Business Analyst, you must have a job title containing these words. Nope. Not true. Anyone can perform Business Analysis tasks, regardless of their job title. There are many roles in which people are practicing the profession without even realizing it (this is what I did for the first part of my technology career). Business Analysis is only about writing requirements. Also, emphatically not true. While eliciting, modeling, and documenting requirements can be a part of the job, it’s certainly not the only part. Business Analysts do much, much more than just pumping out long lists of written requirements. You can’t become a business analyst without a college bachelor’s degree. Nope. I didn’t even have an Associate Degree when I became a Business Analyst (I have since earned by Bachelor Degree). I started out on the technical side and transitioned to Business Analysis due to a merger and acquisition. While a 4-year degree might give you a good foundation, you’re almost better off going to a technical college and getting a 2-year Business Analysis degree that aligns with the BABOK® so when you graduate, you already meet the criteria to sit the mid-level BA certification exam (CCBA). Data is central to being a Business Analyst. Nope – not necessarily true. While some BAs may use data in their context, it really depends on the role and the organization. If you’re a Business Analyst on a Business Intelligence team, you may very well live and breathe data all day, every day, but in other settings and situations, you might never look at data. SQL is a required skill to be a successful Business Analyst. Again, this is NOT a necessary requirement to become a Business Analyst. While it can be useful to have technical skills like this, they’re certainly not foundational to being a BA. And, assuming you’re a continuous learner due to your curious nature, you can always add this skill to your toolbelt should the need arise! You can’t get ahead in the profession without being certified. This is not necessarily true. Some of the top names in our profession who have authored books and run their own consultancies do not possess a single Business Analysis certification. While there are many benefits of being certified, it’s certainly not the only path to success when it comes to the BA profession. You must be technical to become a Business Analyst. Also, not true. It can be useful to come from a technological background, depending on what kind of industry you’re in, but a lot of the best BAs have no tech history. Business Analysts can come from the business side as well, and in some ways, this is advantageous. Business Analysis is a stepping stone to a career in Project Management. In my mind, nothing could be further from the truth. These two professions are almost exactly the opposite. Business Analysis is a creative pursuit for the curious among us. As BAs, we love to ask questions and keep probing to find the answers, whereas Project Managers are very high-level, focusing on the aspects of project delivery including scope, budget, and timeline. Business Analysts are subordinate to Project Managers. Again, totally untrue from my perspective. I consider these roles to be peer roles, and together, they can combine to create a dynamic duo. There is some level of overlap between the roles, which are opportunities for collaboration. Business Analysts are the decision makers. Nope. This is one of the main distinctions between Product Owners and Business Analysts. As an analyst, you must clearly define the problem or opportunity, and present solution options for the person who is authorized to make the decision. A Business Analyst may make a recommendation based on the findings of their analysis, but the ultimate choice is made by someone else. Business Analysts are not leaders. Absolutely, totally false. Leadership is inherent in being a Business Analyst. We have the skills to facilitate and drive toward successful outcomes – you can’t do this successfully without being a leader. Business Analysts must be extroverts to be successful. Nope. In fact, I would almost bet money that there are many more introverted Business Analysts than extroverts. It seems counterintuitive in many ways, because of how important it is to communicate and collaborate with stakeholders and others in this role, but analysts require quiet alone time to process the data they elicit and analyze their findings. You must have a deep knowledge of the business domain to be successful as a Business Analyst. Maybe, maybe not. In recent days, there have been debates about the generalization versus specialization topic. It really depends on your context and your organization. I have spent the last ten years as a consultant, so it was not to my advantage to do too deep a dive into the businesses of any of my clients. I needed to know “just enough, just in time” to get the job done. However, if you’re an employee of a company in a specific industry, for example healthcare, finance, or insurance, you may benefit from also being a subject matter expert. This could involve getting a deep education and understanding of your industry, which would probably make you more effective and efficient in your role. Business Analysts are not involved in testing. While the act of performing quality assurance activities is not necessarily part of a BA’s job description, their work products are integral to the development of test cases and solution verification and validation. Whether it’s a traditional requirements document or an agile set of acceptance criteria for a user story, the Business Analyst’s work drives the delivery of a quality product. In some organizations and contexts, a BA would in fact also perform a QA role, which is common (but doesn’t mean that this is a core skill a Business Analyst must possess). Business Analysts are only needed on large projects. I don’t care how big or small the effort is, any project or product can benefit from the skills of business analysis. Depending on the size of your organization, Business Analysis may be performed by any number of different roles. In super small companies, people often wear multiple hats, and it’s common for developers to also function as Business Analysts. In larger organizations, you could have multiple levels of Business Analysts, from lead positions to entry-level associates. Anyone can be a Business Analyst. Actually… not so fast. In fact, no. Not just anyone can be a Business Analyst. This profession requires a broad breadth of knowledge and skills, in addition to many underlying competencies (aka soft skills) that are necessary for someone to competently perform in this role. It's not easy, but it is rewarding! Business Analysts are merely order takers. This has always been one of my biggest pet peeves when it comes to misunderstandings about Business Analysis. In the early days of the profession, this may have been somewhat true, but in today’s world, nothing could be further from the truth. BAs must always question the stated need to get to the root cause, which is the actual business need (and usually different from the original request). Organizations can be successful without Business Analysis. Nope. I don’t care whether the company recognizes it or not, but somehow, some way, someone is performing Business Analysis, however rudimentary it may be, to achieve any level of success. Companies that recognize the value of business analysis are typically orders of magnitude more successful than institutions that do not acknowledge or invest in these skills. Business Analysts follow a prescriptive process that is the same for each project. False, false, false. There’s absolutely nothing in the BABOK® that requires anyone to follow a repeatable, stepwise process. Each project and product are different, as is the context in which the work is done. Business Analysis is about choosing the right approaches, tools, and methods for the problem at hand. Every effort performed by a Business Analyst is tailored to the unique situation. - Business Analysis activities are “one and done.” Nope. Business Analysts are ideally involved throughout the entire life cycle of a project or product, which involves continual Business Analysis. Regardless of whether the project is agile or more traditional waterfall, the analyst is important to the verification and validation of the solution to ensure it meets the business needs of the organization.

Final Thoughts

There you have it! 20 Myths about Business Analysis - debunked! I hope you have a better understanding about what the profession is, and isn't, now! Are there any other myths I missed? If so, let me know in the comments below! Read the full article

#analysis #business #cbap #ccba #IIBA #myths #profession #professional

0 notes

rachaelwilterdink · 3 months

Text

How to Scrum without a Scrum Master

The Scrum Guide defines three roles or accountabilities on a Scrum Team, including: - Scrum Master - Product Owner - Developers (aka Team Members)

So, can Scrum Teams exist and operate at their best sans a Scrum Master? As a consultant, I have seen companies do various things to avoid having to employ someone in this position, with mixed results. Here are some configurations teams have tried:

Scrum Master Responsibilities are Shared by dedicated Team Members

Some teams I have seen decided that rather than hiring a Scrum Master, they would split the responsibilities of a Scrum Master amongst the team members. For example, one person would facilitate the Retrospectives, another would run the Sprint Planning meeting, etc. Each person volunteers for whatever portion of the role they want to perform, and that is their permanent Scrum Master job going forward. While this idea in theory allows one person to master a particular piece of work, it could also get boring quickly.

Scrum Master Responsibilities are Shared on a Rotating Basis

Each Sprint is a new opportunity for team members to perform a different aspect of being a Scrum Master. Rather than always having the same assignment, individuals can try out other facets of the role. Sharing responsibilities this way gives each person a chance to try something different and learn something new each Sprint, which helps keeps it novel and fresh.

Random Scrum Master Role Rotation

In this model, it’s a game of chance – you never know who the Scrum Master will be. This one person assumes all the responsibilities of a Scrum Master for a Sprint, thereby reducing their capacity as a developer on the team. It could be based on rolling dice, picking straws, or spinning a wheel (a la Wheel of Fortune). The drawback to this approach is that someone could have their name come up in consecutive Sprints, which doesn’t exactly spread the love.

Scheduled Scrum Master Role Rotation

Another option is to just put all the team members into a scheduled rotation, so each person would know (well in advance) when it’s their turn to play the Scrum Master. Personally, I like this option because it allows the person time to prepare for acting in this role ahead of time. It can also work well when having to make changes due to vacation, etc. – people can just work out a swap.

No Scrum Master

Another alternative is to just ignore the Scrum Master role altogether (leaving the team rudderless and adrift). With no one at the helm of the ship, it could end up anywhere because no one is pointing the way or supporting the team by seeing the big picture. I don’t advocate trying to operate independently.

Let the Scrum Master Go… Slowly

I have always said that being a Scrum Master is like being a parent – your job is to work your way out of a job. But you wouldn’t leave your toddler to fend for themselves – you would wait until the person in your care was mature and fully capable of not only surviving, but thriving, before exiting. The same is true of a Scrum Team – all teams can benefit from having a Scrum Master in some capacity, until they don’t think they need one anymore. Until then, I’d have at least some semblance of a Scrum Master, even if only part-time, or if only a shared resource.

That’s a Wrap

I know this is a short blog – I’m out of practice – but I hope you found it useful. Love ‘em or hate ‘em, Scrum Masters or people performing their duties can help a team keep humming along. If your organization just doesn’t see the value, or simply can’t afford to have a Scrum Master on your Scrum Team, find a way to see that someone, somehow, is leading the team in the right direction. If you have seen or experienced anything else when it comes to having (or not having) a Scrum Master, I would love to hear about it, so let me know in the comments below! Read the full article

#agile #master #scrum #teams

0 notes

rachaelwilterdink · 7 months

Text

10 Symptoms Your Scrum Team is Broken, Part 1

I have been on some really successful and well-oiled Scrum Team machines, but I've also shared in the misery that is broken Scrum (aka Zombie Scrum, Fake Scrum, or whatever other term you give to dysfunctional groups of people who work "together," but aren't really operating as a team). As such, I'm writing two blogs on how to detect that something might be wrong with your Scrum Team. Here are 10 symptoms to watch out for in Part 1: - Not creating Sprint Goals Nothing spells a dysfunctional Scrum Team like the lack of Sprint Goals. This is one of the most persistent mistakes I have seen most teams make. Not having Sprint Goals means there’s nothing to aim toward during an iteration – no North Star. What usually ends up happening is that the team ends up picking a disorganized hodge-podge of different things. This results in a Frankenstein-style set of stuff to share at a Sprint Review, and it ain’t pretty.

- Biting off more than you can chew Another extremely common behavior I have seen by bad Scrum Teams is that they always bite off more than they can chew. This could be the result of intense pressure by the business, or just an inflated sense of what the team can do. Rather than constantly overloading each Sprint, the team would be better off taking a pause and getting realistic about their capacity to deliver. Then, they could pick a smaller set of stories and focus on getting them all the way across the finish line. It feels good to deliver and be successful! Ridiculously Unrealistic Estimates One root cause of the last problem might be that teams also suck at estimating. And when I say this, I mean it both for relatively sizing stories AND estimating times for tasks. This could go either way – by overestimating to add “padding” or underestimating because the team hasn’t really thought through what it will take to deliver (they need to consider more than just size – complexity, risk, technical knowledge, etc. are also important to think about). At one extreme or the other – it just doesn’t work.

No estimates/sizes at all I’m not sure if it’s worse to have no sizes or estimates at all – sometimes this can be a sign that the team has reached the nirvana of Scrum, meaning they are so stable and predictable that they don’t need to spend time doing these activities because they all intuitively know what they can accomplish together. However, most of the time, this is not the case. When stories have no sizes and tasks have no time estimates, you’re sort of flying blind and have no way to measure progress (other than delivering a working product at the end of each Sprint). Burndown Going in the Wrong Direction I like to see a Sprint Burndown chart follow the ideal trend as much as possible. It’s bad when it stays flat throughout a Sprint, but what’s worse is seeing the burndown go up, instead of down! This is a symptom that the team has added more items to the Sprint Backlog during the Sprint, they’re not burning down their hours on active tasks each day, or they have added time because they discovered something that they didn’t expect. When this becomes a trend, the Scrum Master might do well to question the team and challenge them to find a solution.

- Too much Work in Progress While The Scrum Guide says nothing about limiting Work in Progress (WIP), this is an element of Kanban that many teams ought to adopt. Ideally, the team is working their way down from the top of the Sprint Backlog, focusing on the highest value/priority items first. But I often see that individual team members get stuck, and rather than working through their impediment or asking for help, they move on to something else so they’re not sitting idle. But once you start working on more than one thing, your time is split, and you start context-switching, which means you’re less efficient and it's more likely that none of the things you are working on will get done. It’s all about focus. - The focus is more on utilization than outcomes Related to the previous item, many organizations still think the most important thing to worry about is utilization, or how much a person spends their time being productive. I find this silly, especially at this time in history. I really don’t care that every minute of every day is filled with some kind of work. For knowledge workers especially, people need time to think, and to worry about delivering a valuable business outcome – they don't need to do non-value-added work because they happen to be idle. - Team members work independently in silos rather than together Scrum took its name from the game of Rugby. So, what does it mean to be a team? It means more than each person doing their individual component parts – it requires working together to get things done. A sports team would never, ever win if they worked the way a lot of so-called Scrum Teams do. It’s supposed to be a team sport – not an individual one. Putting multiple heads together usually accomplishes much more than just one.

Constantly shifting Sprint Backlog I like to think of the Sprint Backlog as a baseline against which to manage the change while a Sprint is in progress. Once the Sprint starts, and assuming you do have a Sprint Goal, the whole team should be focused on accomplishing that goal, but instead, interruptions and change (aka churn) keep changing the target, and as everyone knows, it’s very difficult to hit a moving target. Inasmuch as possible, the Scrum Team should self-regulate and limit any adjustments to protect their ability to reach their Sprint Goal. - Stories that carry over time and time again Talk about de-moralizing. When a Scrum Team has stories that carry over from Sprint to Sprint, to Sprint, it means that nothing is getting across the finish line. There could be good reasons for this, and often there are, but when this becomes a habit, it’s a symptom that something is wrong. It could be that the story was poorly sized (too big or complex), the person doing the work wasn’t competent to perform the work, or there was a fundamental lack of understanding of the request. No matter what the underlying reason, this doesn’t look good to your stakeholders, and it makes your team look bad. You need to stop, analyze the root cause, and find a solution.

Capture from the movie "The Neverending Story"

Final Thoughts

So, there you have it - the first 10 symptoms that there's something seriously wrong with your Scrum Team. I wouldn't be surprised if you have seen one or all of these signs. If you have any tips or suggestions about what people can do to address these issues, please let me know in the comments below. And... stay tuned for Part 2, in which I explore 10 MORE symptoms that your Scrum Team is broken. Read the full article

#agile #broken #estimates #fake #goals #scrum #sizing #sprints #symptoms #zombie

0 notes

rachaelwilterdink · 8 months

Text

How to Help Leaders Understand Agile

Agile: Not Just Another Buzzword Anymore

Around a dozen years ago, I attended a business analysis conference where a colleague presented a session on Agile – a concept our organization had recently embraced. At the beginning of the presentation, the speaker asked how many in the room were Agile practitioners. Out of the 50-75 attendees, only about 15% raised their hands. That was back in 2011. Fast forward to 2023, and the situation has completely reversed. I estimate that approximately 75-80% of companies have adopted Agile in some way, shape, or form, leaving the laggards stuck in the early 2000s. The shift from Agile being perceived as a new and shiny tool to a firmly ingrained idea within companies signifies a significant transformation. Those who haven't embraced Agile now face a severe competitive disadvantage and must modernize their methods to stay relevant and avoid extinction.

Top-Down Support: The Key to Successful Agile Transformation

Throughout my time as a consultant, I've worked with various organizations at different stages of their Agile journeys – from novices to highly mature teams. A consistent observation I've made is that without leadership support, Agile transformation efforts are likely doomed to fail. While bottom-up, grassroots efforts can succeed in creating self-organized Agile teams, they often remain under the control of a Project Management Organization with bureaucratic constraints. Consequently, these teams might achieve some success, but they will never reach their full potential or become truly Agile.

Leaders Must Embrace Agile Fundamentals

A modern-thinking leadership team that buys into Agile is undoubtedly a win, but it's not enough. Many C-suite executives still view Agile as a buzzword and may back it only when it's popular and convenient. When trouble arises, they tend to revert to traditional practices. For leaders to be effective supporters of Agile, they must genuinely understand its key fundamentals. This requires a shift in their mindset, which can be particularly challenging for traditionally educated MBAs. Education becomes the key to helping leaders grasp the essence of Agile. While they might not have the time for full-fledged courses, a couple of hours of training can equip them with enough knowledge to recognize Agile jargon, articulate its benefits, and distinguish it from traditional project management.

Scrum: Simple to Understand, Difficult to Master

Leaders who encounter the Scrum Framework or other Agile methodologies often perceive them as straightforward. Indeed, Agile methods are easy to grasp at first glance, but, as The Scrum Guide explicitly states, they are difficult to master. It's essential to differentiate between merely doing Agile and truly being Agile. The former involves going through the motions or cherry-picking elements while neglecting critical aspects like continuous improvement. Being Agile represents a complete shift in mindset and perspective, which is not easy for individuals, teams, or entire organizations to achieve.

Leaders as Agile Evangelists

Once leaders have been educated about Agile, showcasing results is the best way to reinforce its importance. Consistently delivering on a regular cadence generates excitement and feedback, which is crucial for fostering Agile practices. When executives witness tangible results, they are more likely to remain supportive. Agile teams, equipped with the ability to pivot and adapt, are not hindered by setbacks. As leaders experience the openness and transparency of Agile practices, they are more inclined to trust their teams and share success stories, further propagating the Agile mindset.

It’s a Journey, Not a Destination

As the saying goes, Agile transformation is a journey, not a destination. The process involves striving for a greater ability to respond quickly and using empirical processes for inspection and adaptation. Throughout this journey, there will be ups and downs, twists and turns, but there is no date on the calendar that proclaims an organization as "officially Agile." Becoming truly Agile is an ongoing process that requires practice, trial and error, experimentation, and trust. In my experience, this journey can take years, and there is no definitive endpoint.

Final Thoughts

Becoming Agile is no simple task, especially when leadership lacks understanding and support. However, when leaders are educated and enthusiastic about Agile's benefits, they become its most ardent advocates. Now, I'm eager to hear about your experiences. How have you seen situations where leadership failed to understand Agile? Have you encountered successful or unsuccessful grassroots efforts? Feel free to share your stories in the comments below. Read the full article

0 notes

rachaelwilterdink · 11 months

Text

More Great Agile Debates, Part 2

In the second part of my new blog series on "Agile's Great Debates," I cover another set of five topics that people tend to argue about when it comes to agile ways of working. Here they are: - SAFe is an Agile Framework - You Should Show “Not Done” Work at the Sprint Review - The Sprint Review is a Status Update - Agile is the same thing as Scrum - The Sprint Review and Retrospective are the Same

SAFe is an Agile Framework

I know I’ll probably get a few haters when I say this, but NO!, I don’t view SAFe as an agile framework. It’s a bloated, complicated (and bastardized) way of trying to accomplish large and overly complex, integrated work. (Seriously, visit their site and you will instantly see what a mess it is.) As an agile consultant, my recommendation is usually to avoid scaling if at all possible. By attempting to scale, you increase cost and complexity, and the risk of failure is much higher. It’s highly preferable to keep atomic and autonomous agile teams that are small and focused.

However, if you feel you must scale, there are (in my humble opinion), far better options than SAFe. These include Less and my scaled agile framework of choice: Nexus (which was created by the same people who wrote The Scrum Guide).

You Should Show “Not Done” Work at the Sprint Review

Uh, duh – NO! This is a cardinal rule of Scrum. Every team must have an agreed-upon Definition of Done, which is an official artifact in Scrum. And if an item does not meet this definition, it is not “Done,” and therefore should not be shared in a Sprint Review. Unfortunately, there are many Scrum Teams that struggle with this. First off, many lack a Definition of Done, and without one, how does anyone know what “done” looks like? Short answer: they don’t! This means that stories can linger and change, because nobody knows where the boundaries are.

Teams may also be tempted to show things that are “mostly” baked. This usually means that the coding has been done and it’s been passed off to QA for testing, but testing is in progress and hasn’t been completed. Some Scrum Teams cheat to get around this irritating problem by adjusting their Definition of Done so it doesn’t include “QA tests passed without any critical- or high-severity defects.” Try not to be this team. Having a tested, working, useable, demonstratable, and potentially-releasable working increment is the whole point of each Sprint!

The Sprint Review is a Status Update

Honestly, this is one of my biggest pet peeves when it comes to agile and Scrum! NO! The Sprint Review is not merely a status update or a demo; this event should be much more than that (and it should replace the dreaded “Status Review Meeting”). The point of the Sprint Review, according to The Scrum Guide is to: “Inspect the outcome of the Sprint and determine future iterations.” Yes, you should show your actual, working increment(s). This should not be a facsimile or a PowerPoint. Not only that, but the Developers should lead this event. They did the hard work of building the backlog items, and they deserve to get the recognition and credit that comes along with delivering. The second, and very important part, of the Sprint Review is to come up with a plan for future iterations. In my experience, the Product Owner has a general idea of what is wanted in the next Sprint or two, and shares this plan with the audience. However, based on stakeholder feedback, that tentative plan may change to accommodate new user requests. At the end of the Sprint Review, the expected outcome is an updated Product Backlog that serves as the input to the next Spring Planning event.

Agile is the same thing as Scrum

There is a widespread and common misunderstanding between agile and Scrum. This occurs because the Scrum Framework is far and away the most popular of agile approaches, but it’s definitely not the only one. Nor is agile synonymous with Scrum. The way I describe this concept when training new Scrum Teams is that agile is a mindset, an umbrella that covers all the various aspects of different agile approaches. All the different “flavors” of agile, therefore, are agile, but they are not agile itself.

To better understand what agile is, the best resource (in my humble opinion) is the original Agile Manifesto, which was famously penned by a group of frustrated software developers who met in Park City, Utah, at a ski resort in my wonderful home state of Utah in 2001. My first child was born the same year, making the document 22 years old, which is relatively new in the grand scheme of technology. In the Agile Manifesto, there are things that are valued more than others (which is not to say the other things don’t have any value). It also includes 12 core principles. Although agile has evolved past software development, the same ideas still apply to other contexts.

The Sprint Review and Retro are the Same

As an agile trainer and coach (Scrum specifically), I have seen that the two Scrum events that are most often confused, are the Sprint Review and Sprint Retrospective. I don’t quite understand why there is so much confusion, but my experience has proved it time and time again. To clarify, NO, these two events are not the same thing. Each has its own purpose and audience, along with expected outcomes. The goal of the Sprint Review is to: “Inspect the outcome of the Sprint and determine future iterations.” In contrast with the Sprint Review, the Sprint Retrospective is only for the Scrum Team, without any outside or extra participants (including managers). The point of this event is to embrace the empirical process of inspecting and adapting. It allows the team to honestly look back at the Sprint and identify opportunities for improvement. So, as you can see – the Sprint Review and Retrospective are two totally separate events, with totally different purposes. I hope this clears up any confusion!

Final Thoughts

This blog covered five more ways agile concepts and practices are misunderstood. To recap: try not to scale if you can avoid it, make sure your team has a Definition of Done, only show "done" work at the Sprint Review, which is a separate event with a different purpose than the Retrospective. Finally, agile is a mindset - Scrum is an agile framework. Now, as always - it's your turn! What do you think about these debate topics? Do you have any differing opinions or experiences? If so, I would love to hear about them in the comments below! Oh, and P.S. - if you missed the first blog in this series, you can find it here: - Part 1 - Devs as Sub-team, the 3 questions, product goal, refinement, hybrids Check back for more great debates soon! Read the full article

#agile #done #increments #mindset #planning #retrospectives #safe #scaling #scrum #Sprint

0 notes

rachaelwilterdink · 11 months

Text

More Great Agile Debates, Part 1

My previous presentations and blogs on "Great Agile Debates" have proven extremely popular, so I thought I would add to this body of knowledge with a new blog series. In each blog, I will cover five more great agile debates for your consideration. Keep in mind that my opinions are my own, and not necessarily those of any other organization I am affiliated with. I'd also love to hear what you think, so don't be shy - leave some comments, and let's debate! Here are the first five topics of debate about agile I will cover: - The Developers are a Sub-team in Scrum - The Three Questions are Required - A Product Goal is Not Required - Backlog Refinement is an Official Scrum Event - Teams Cannot Combine Different Agile Elements

The Developers are a Sub-team in Scrum

This is now FALSE! In previous versions of The Scrum Guide, the Developers were considered a sub-team within a Scrum Team, but in the 2020 update to the guide, this concept was removed. The point of this change was to ensure that the team is a cohesive whole – without having a team within a team. The former Dev Team concept created an “us versus them” attitude between the Developers, the Scrum Master, and the Product Owner. Going forward as one united team, many things that were once in the domain of the Dev Team are now jointly owned responsibilities among the entire Scrum Team.

Further, having everyone on the Scrum Team on equal footing as team members allows people to collaborate and build trust more easily. Everyone on the team should be “in the know” on what’s happening, without any surprises from the separateness of having a sub-team.

The Three Questions are Required

This, too, is now FALSE! In the previous versions of The Scrum Guide, the three questions were, in fact, the prescribed format for running the Daily Scrum. As a reminder, the questions were: - What did I do yesterday that helped the Development Team meet the Sprint Goal? - What will I do today to help the Development Team meet the Sprint Goal? - Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal? The creators of the guide realized that requiring the answers to these three questions was far too prescriptive. Their goal was to simplify the framework. Many Scrum Teams had already stopped using the three questions because it felt rote and repetitive. Answering these questions didn’t really give the team the real opportunity to figure out their collective plan for the day toward accomplishing the Sprint Goal.

I myself had already stopped using this format on my Scrum Team. A far better exercise is to “walk the board” – going through your Sprint Backlog and looking at each item (either by person or from top to bottom) and its progress. Having this visual also helps to identify if there are any impediments, whether some team members are overloaded while others might not have much to do. There are other options, as well. The main idea is that you can choose the format that works best for your team in your context. Some teams prefer to post on a collaboration channel like Slack or Teams, while others simply go round robin verbally, without focusing on what has already happened – rather, looking forward to what needs to be accomplished today.

A Product Goal is Not Required

You guessed it – WRONG! A Product Goal is now required. Prior versions of The Scrum Guide did not include this concept. In the absence of this as a requirement of Scrum, many teams and Product Owners introduced their own idea to fill the void: Product Vision. Some people might argue that there is little difference between a vision and a goal. I struggle with this myself, especially having trained many Product Owners and helped them craft Product Vision Statements.

In training new Product Owners, I now feel obligated to include the Product Goal as it is now an official aspect of Scrum. The way I see it, these can be two separate things. The vision is the aspirational description of what the product is and how it is beneficial, which is strategic in nature. On the other hand, the Product Goal (or goals) is more tactical, with specific measurable objectives similar to SMART goals. These provide more direction on what is needed to achieve the vision.

Backlog Refinement is an Official Scrum Event

Sorry, folks! This one isn’t true, either (at least not yet). While The Scrum Guide infers that Backlog Refinement is an important, ongoing activity, it’s not an officially recognized Scrum event. Personally, I would like to see this added as an “official” requirement of the Scrum Framework. To be successful in any type of endeavor using Scrum, whether project- or product-based, having a properly managed Product Backlog is essential.

Many teams only do this activity on an ad-hoc basis, which is inconsistent and unpredictable. I prefer to have this activity, if running two-week sprints, on the opposite day from the Sprint Review. This ensures that Backlog Refinement actually happens regularly. I would also suggest a timebox similar to that of the Sprint Planning event. These events are very similar, but Backlog Refinement is a preliminary opportunity for the team to review and discuss upcoming stories, answer any open questions, and gain a shared understanding of each item. The team can also use this session to size the stories. Having done this work in advance also speeds up Sprint Planning.

Teams Cannot Combine Different Agile Elements

Once more, FALSE! There is no rule written that people cannot combine different aspects of various agile practices. Most Scrum Teams also use Kanban boards, and other concepts borrowed from lean, XP, or other agile frameworks. Scrum alone isn’t always sufficient to create all products or solve all business problems. Support teams, for example, would be much better suited toward sticking with Kanban, but may also use Scrum activities such as periodic retrospectives to look for improvement opportunities. Likewise, traditionally run projects (aka waterfall), can also benefit from inserting some agile ideas into their projects. They too may have more frequent retrospectives, rather than end-of-project Lessons Learned (when it’s too late to do anything about it).

For teams that want to avoid full-blown scaling, they might simply take from the Nexus scaling framework (or others) to achieve some parts of scaled agile, without adding too much additional overhead and cost. The Project Management Institute also offers a certification in Disciplined Agile, which I would call a compilation of all kinds of agile ideas, that can be combined in whatever fashion makes sense and works for your team.

Wrapping it Up

Thank you for reading! This is just the beginning of many more great agile debates, so come back often! And, if you have an alternate opinion, I would love to hear it - please post in the comments below! Read the full article

#agile #debates #iterations #ownership #planning #products #retrospectives #reviews #scrum #sprints #teams

0 notes

rachaelwilterdink · 1 year

Text

The Great User Story Debate: To Assign or Not to Assign on Agile Teams

An interesting question came up during a recent Sprint Planning session; this is a topic that somehow escaped my list of “Great Agile Debates,” but since it’s currently on my mind, I decided to write a quick blog about it (Full disclosure: I had a little bit of help from ChapGPT4). The question is: “Should Sprint Backlog Items (aka User Stories) be assigned to an individual, or left un-assigned?” Keep in mind that I am talking about the Story level – not the Task level (that’s another topic for another day).

I have seen some teams that don’t do any assignments and others that do. There are compelling arguments both ways, and I have also received conflicting advice from different Agile coaches that I have worked with over the years. Having observed it being done either way, I have my own opinion about this (but I’m always willing to be convinced otherwise). From my experience, I prefer to have developers “volunteer” for stories (not be volun-told), rather than having them be assigned by someone else (say, a manager). By signing up for an item, it means that you’re the primary contact for that story, and this helps people more clearly communicate about it. However, this doesn’t necessarily mean that the person is solely “responsible” for completing the item – in agile, the whole team is ultimately accountable for delivery. Also, each story could have multiple supporting tasks that are done by different team members, and having a single point person is less confusing.

On the flip side, it’s nice to leave some things unassigned. Some teams I have been on only made Story assignments for the top few items in the Sprint Backlog during Sprint Planning – maybe one per team member. Then when a Story was completed, the team member picked up the next item on the board, in order of priority. The potential problem with this is that not all team members have the same skills and knowledge. However, I think this is a good opportunity for people to learn new skills and move away from being exclusive specialists to becoming more generalists. All that said, here are a few pros and cons for either leaving Stories unassigned or assigning them: Leave Stories Unassigned PROS: - Promotes collaboration and cross-functional teamwork. - Allows team members to choose stories that align with their strengths and expertise. - Encourages the opportunity to cross-train on items that might be new or unfamiliar. - Fosters a sense of ownership and accountability for the whole team's overall success. - Helps ensure that work is flowing efficiently by allowing team members to pick up stories as they become available. Assign Stories to Individuals PROS: - Provides a clear point of contact for stakeholders and other team members to discuss specific stories. - Can help manage dependencies and ensure that work is being completed on time. - Provides clarity around who the point person is for a particular story. - May help ensure that team members are working on stories that align with their strengths and expertise. CONS: - May lead to uncertainty around who is responsible for a particular story. - Can make it difficult to manage dependencies between stories. - May require additional communication and coordination among team members to ensure that work is being completed effectively. CONS: - Can create silos and limit collaboration between team members. - May result in knowledge gaps if team members are only working on stories in their assigned areas of expertise. - May lead to a lack of flexibility if team members are not able to take on additional work as needed. - Can make it difficult to adjust to changes in the project scope or timeline. At the end of the day, I don’t think there’s necessarily a right or wrong answer to this question. I think it’s a matter of team needs and preferences. There could also be a happy medium that applies the best of both worlds. In my case, I take it on a team-by-team basis and experiment with what works well, and what doesn’t, and in true empirical fashion, use the data to inspect and adapt.

What do you think? What does your team do in terms of assigning User Stories (or not)? I’d love to hear about other people’s experiences, so please share your thoughts with me in the comments section below! Read the full article

#agile #assignment #backlog #debates #planning #scrum #stories

0 notes

rachaelwilterdink · 1 year

Text

My Scrum Team Doesn't Want to do some Events

I have been part of countless Scrum Teams. And although no two teams do everything the same way, one bad habit I have seen many teams adopt is the notion that it’s okay to skip some Scrum events. How do they justify skipping important activities? Let’s see…

Possible Justifications for Skipping Scrum Events

Holidays One easy reason to decide to skip a Scrum event is the holidays. When a holiday falls smack on an important day in a Sprint, it can be very difficult to re-schedule the event. Not only that, but people tend to take extra time off surrounding holidays, so it’s highly unlikely that all the necessary participants will be present to attend. Based on timing, I’ve even experienced entirely skipped Sprints (usually between Christmas and New Year) because almost everyone is off. While not normally advisable, holidays are a somewhat legitimate reason to occasionally skip Scrum Events.

Stakeholder Unavailability Sometimes, your stakeholders have other things going on, and they just can’t make it. Perhaps they’re all attending a conference or training, or it’s summer and a bunch of people have taken vacation time off. When there’s no one there to show up at your Sprint Review, it’s a waste of time for everyone else. As an agile coach, in this type of situation, I suggest that teams go ahead with the Sprint Review at the normally scheduled date/time but record it so stakeholders can view it at their leisure and provide feedback when they’re back. Nothing of Value to Show at the Sprint Review If your team decides to take on a bunch of technical stories or research spikes, you might not have anything of tangible value to show stakeholders. No one wants to show up to an art museum with no art in it. Not having anything valuable to show is a huge problem, especially if it becomes habitual. If you don’t have anything to share, have the meeting anyway, and be honest and transparent with your stakeholders about why. They might not like it, but they usually tend to be understanding (especially if it's very rare).

Your Team is Truly High performing That unicorn – the high-performing team – does happen from time to time. When it does, the team has usually gone through hell and back together, and they are now a well-oiled machine. If you’re in this enviable position, you might be tempted to skip events such as the Sprint Retrospective. You might be staring at each other saying “We don’t have anything to improve upon.” In this case, I would challenge the team to try a different type of Retrospective activity – one that will take another perspective so the team can still gain insights on potential changes they could make. Activities become Rote and Boring Following on the last item, some of the Scrum events can get repetitive – feeling rote and boring. No one enjoys being in long meetings that seem like a waste of time (even if they’re not). Of the Scrum events, the most likely meeting to be skipped is the Sprint Retrospective; this is especially true if the activity is always done using the same format (such as “What went well? What didn’t go well? What can we improve?). If I were on a team like this (and I have been), I would also want to skip it. The remedy is to mix it up – choose different types of games and methods to inspect and adapt. Make it FUN!

Firefighting Things always come up – it’s inevitable. But this shouldn’t be something that happens every day. Production support issues tend to stop whole Scrum Teams in their tracks, as they should. However, if you have to skip a Scrum event for this reason, it should be rescheduled as soon as possible after the problem is resolved. If this seems to happen frequently, for most Scrum meetings, you probably have a bigger problem on your hands (and should probably get to the root cause of it so you can prevent it from happening). The Work can be done Asynchronously Sometimes, people just don’t want to get together to meet. Call it meeting fatigue, or whatever else, but I can relate to the feeling. I like to have at least one day per work week where I can be “head down” without any interruptions to kick me out of my state of flow. Meetings do exactly that. Some Scrum Teams I have been a part of decided to do their Friday Daily Scrum as a post on a Slack or Teams channel rather than as a meeting. While this is understandable, it’s still not preferable, as there's no two-way communication, only one-way.

They Feel Redundant I am guilty of this sin of skipping Scrum events. Part of it has to do with timing. When a Sprint has ended, and the next one begins, I don’t find any point in holding the Daily Scrum. We capped off the last iteration with our Sprint Review and conducted our Retrospective. Then, we move right into planning for the next Sprint. It makes no sense to me to have a Daily Scrum when everyone knows what they did and what the plan is for the next iteration. (I’d love to hear any thoughts from other practitioners about this justification.) Offshore Team Members’ Schedules Finally, when your Scrum Team is comprised of team members in different time zones across the world, it’s often impossible to get schedules to align. When this happens, your team might need to get creative about how to communicate and collaborate in a way that works for everyone. It might mean recording a session or having someone who can straddle the time zones and act as a go-between for the team. These aren’t great solutions, but when this situation is unavoidable, you must do what you can to get the job done.

Reasons NOT to Skip any Scrum Events

Lack of Consistency When Scrum events happen inconsistently or erratically, the team loses a sense of predictability and stability. The meetings are meant to provide a regular cadence, with set time boxes so the team can know what to expect during each Sprint. When things are constantly moving, changing, or being skipped, something is going to go wrong – you can’t avoid it. It might be a miscommunication, a missed requirement, crossed wires, or reduced quality – you get the picture. Team Disconnect If your team decides, for instance, that they don’t need to meet every day for a Scrum, and instead only hold it a few times a week, you’re instantly setting yourself up for trouble. Each day, your Scrum Team has the opportunity to plan what it will accomplish and raise any impediments that need to be resolved. If this doesn’t happen, you run the chance of having open blockers preventing the team from making progress toward the Sprint Goal. Not only that, but a sense of social isolation and disconnectedness can creep in, making individuals feel less like a cohesive team (and consequently, more likely to quit).

It's Too Long Between Feedback Loops Every single Scrum event is another opportunity to apply the empirical principle of inspecting and adapting – you don’t just have to wait for the Sprint Retrospective to make improvements. By skipping events, you essentially delay getting useful feedback that could cause you to make meaningful improvements, either to your team processes or the increment you’re building. You’re No Longer Practicing Scrum It says right in The Scrum Guide that if you don’t do all the Scrum events, you’re not practicing Scrum. While this is a framework, not a methodology, you still need to be cautious not to cut out any of the essential elements that comprise Scrum. If you do, you can no longer claim that Scrum is how you’re operating. If you have already started down the slippery path of skipping events, I would suggest having a team “reboot,” re-educating the team, and getting all the basics back in place so you can be successful.

Team Stagnation If you’re familiar with the Tuckman Model of team formation, you’ll know that teams don’t become high-performing easily. If a team is formed, it might never get out of the storming stage, in which team members lack trust as they try to figure each other out and how best to work together. Team cohesion takes time, and shared experiences. Teams that don’t hold all the Scrum events run the risk of getting stuck in a rut, and never reaching the pinnacle that they could if they worked on it with consistency. Reduction in Quality of the Increment The thing that always suffers most when Scrum events are treated as unimportant or optional is quality. I can’t tell you how many times I have been on Scrum Teams that were anything but agile. Each Sprint, the team would wait to share or show anything with either stakeholders or testers, and by the time the iteration ended – guess what? There was nothing ready to show that met the team’s Definition of Done (assuming they had one).

Final Thoughts

Each event in the Scrum framework has a particular audience and purpose. While skipping events might be tempting or in some cases, make sense, it’s still advisable to put in place and keep all the defined events of Scrum, even if it means re-scheduling them. The drawbacks of skipping Scrum events are evident and will show up in the lack of quality in your increments, and diminished trust from your stakeholders. So, just don’t do it! I would love to hear the experiences or thoughts of other agilists, Scrum Masters, agile coaches, or any other member of a Scrum Team. Please share with me in the comments section below! Read the full article

#scrum #agile

0 notes