Agile Fundamentals For Project Managers And Business Analysts: Fill & Download for Free

I experienced "the days before" asa developer of scientific software, where deadlines were not the primary constraint (c1990–7)a developer of ecommerce software, where deadlines (and budgets) were the primary constraint (1997–9)A technical sales person, responsible for project proposals including scope, schedule, and budget (2000–3).Under #1, I was blessed with humane management and customers who mostly understood that we were doing things that had not been done before. Within reason (2x-3x), "it took how long it took."Also, we never "just wrote the software." The problems were too difficult for that. We got something running as soon as possible, designed as we went, showed intermediate results and got feedback where possible, and used automated tests extensively. In step by disciplined step, we created the solution. We refactored, though we didn't know it was called that. We didn't know anything about lower-case project management. (A little would have helped). Our stuff was small enough, and basic research, so we weren't subject to government-mandated waterfall. Life was great. Fond memories.#2 was a whole new breed of cat. The problems were simple, but the technologies were changing pretty fast, and whatever it was, it had to be ready by a fixed date. We were given a scope, and a strong suggestion of what the "estimate" needed to be. So we gave one, under some level of pressure (ethical employer, we were just dealing with forces we didn't fully understand), and it became a moral and contractual Commitment. I learned what a "death march" was.By #3, we had started doing metrics-based estimation, but that couldn't solve the fundamental problem. The real constraints were date and/or budget, but we were all working under Project Management dogma that said you had to lock the scope and then predict (and commit to) budget and schedule. Uncertainty is a Moral Failing, despite what my data were screaming at me. When you have developers (your friends and former colleagues) working nights and weekends, all the while losing money, and unhappy customers, you get really open to new ideas.Enter Agile, c2003. What it offered, once I heard past the hype and zealotry, was project management that matched reality. It gave us a way to put all the uncertainty in the scope and manage it there, without being out of control. The key was the velocity-and-sprint planning process, and just-in-time specs. Empirical Process Control for software projects! Hooray! (Though I didn't know that's what it was).We bet the division on Agile. We never again had a death march, we always made money, and 12 of 13 customers were referenceable. The division was disbanded when the company was sold.I would never go back. When it looks like my current organization *is* going back, even indirectly, to mandating fixed-scope, plan-controlled project management (there are those in leadership who are attracted to its familiarity, and subliminal siren song of Efficiency, Predictability and Control), I literally develop something like mild PTSD symptoms, and have to consciously calm myself.There's a lot of stupid Agile being practiced nowadays. I get that. But the approach is fundamentally sound, while the old way is not, at least not under conditions of high volatility in requirements, low predictability of effort, and schedule and budget as primary constraints. That is nearly every project I set up (I'm a Business Analyst / IT Social Worker now).They don't know what they want. They really don't. They're scrambling to figure it out.We don't know how long it will take. We really don't. There's significant unfamiliar tech and/or team composition.Delivery dates are really fixed. Semesters and Summer Term start when they start.If your world is like this, and you're not running something like Agile, and grokking why you're doing it, I call "malpractice," maybe on you, more likely on your management. IMO.Dev or not, I'll gladly attend sprint planning or even stand-ups if that's how I get my life back.Executive, what familiarity, dogma, and whispers of "this time will be different," are you willing to abandon, or at least question, to keep projects from blowing budgets and deadlines and delivering misfit solutions?

According to IIBA, Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.A Business Analyst is someone who analyzes an organization and designs its processes and systems, assessing the business model and its integration with technology to achieve a certain objective.Business Analysts need to be technologically competent. As a practicing business analyst, trainer and consultant with Adaptive US, I have come across certain business analysis tools which a BA should definitely know, which will aid in their BA knowledge and work.Fundamentally, we need the following types of business analysis tools:For tracking the requirementsFor describing requirementsModel requirements wherever feasibleCollaboration toolsLet us understand the top 10 software concepts and tools for business analysts.1. Software Engineering Methodologies like SDLC e.g. Waterfall, Iterative (Agile/Scrum)We should be aware of the concepts related to methodologies like Waterfall and iterative. Business analysis approaches differ as per SDLCs followed and being knowledgeable on SDLCs helps us to plan our activities better.2. High-Level Technology like Database structure, OOPAs business analysts, we need to have some flair for technology like OOPS, Database concepts. A good understanding of database concepts is a great skill for all business analysts.3. Reporting ToolsAnother great area of interest for Business Analyst is Reporting tools, BI and reporting mechanisms etc.4. UML Modeling ToolsModeling tools are something like a paintbrush for an artist; we are going to color our canvas with this skill. So get yourself conversant with this tool today if you have not. The popular ones in use in industry are Rational Rose, Star UML (Free software) and Enterprise Architect.5. BPM ToolsBPM Tools like MS Visio and BizAgi (free software) are great tools to depict the process map in a visual manner. Visual representations are great ways to communicate the process flow. The beauty of this is it makes the whole process comprehendable in few mins by having a quick look at the process flow diagram.6. Testing ToolsTesting tools are ultimately going to be the one which is going to make or break the release of the system/application. Business analysts are testers on behalf of the most stakeholders and sponsor for the application to see the light of the day.7. Requirements Management ToolsAs business analysts, we are going to be the owner of the requirements of the applications/projects that we are part of. Few popular requirements management tool in the market are OSRMT – Open source Requirements management tool, DOORS, Rational Requisite Pro.8. MindmapAs business analysts, we are expected to explore details about a particular situation or solution. Mindmap is a very helpful technique to elaborate any concept.9. Prototyping toolsPrototypes are great ways to evaluate and collect feedback on requirements and features.Prototyping tools such as Pencil, iRise, SmartDraw are few popular prototyping tools. Of which Pencil is a free plugin whereas iRise and SmartDraw are licensed products.10. MS OfficeLast but not the least, it may sound very generic, however as business analyst s at any point of time we will have to be fairly proficient on the MS office tools like MS Excel, MS Word, and MS PowerPoint. These office tools are going to be handy for all our life, hence definitely worth to invest some good time in these tools.Keeping one abreast of upcoming technologies, trends and practices in the area of interest or domain are going to keep one in demand.You can get access to the best of the industry toolkit and templates for business analysis and requirements engineering here.To be successful along with the knowledge of these tools you need to hone your soft skills. We all know that hard skills will get you a job but soft skills will take you to the top.Here is a good list of skill you need to acquire/hone over the years to be a better Business Analyst professional:Communication SkillNegotiation SkillFacilitation SkillAnalytical thinking SkillProblem-solving SkillDecision Making SkillAbility to see the bigger pictureAbility to appreciate and empathizeAbility to influence without authorityGood interpersonal skillsYou can refer to the following article for more detailshttps://www.adaptiveus.com/top-10-business-analysis-tools/Moreover, if you are serious about your BA profession, it would be a great thing to get certified. Certifications carry a lot of weight in the industry today.We offer online training programs for CBAP, CCBA and ECBA certifications from IIBA. Adaptive US is one of the market leaders when it comes to BA online training.Please visit the link for more details on the certification and for registrationAdaptive workshop calendarPlease write to us at [email protected] for more detailsHope this helps!!

It sounds like you're trying to do Agile without the role of a Product Owner and that is a very fundamental problem. If you had an effective Product Owner engaged in the project, that problem shouldn't happen at all.Chuck CobbAuthor of "The Project Manager's Guide to Mastering Agile"Check out: Agile Project Management Academy (http://agileprojectmanagementacademy.com/pages/free)