Question: After being team lead for our Customer Operations business unit transformation project, I’ve been offered a position to head the new department. It will now also include Information Technology (IT). Here’s my issue up front: I’m a traditional project manager and now I’ll have nine business analysts and an agile IT team to lead. Who is responsible for what on projects now? I need to figure this out fast.
Business analysts replace project managers, so once you assign a BA to a project, your work is over. All you will need to do is help referee the conflicts between the BAs and the IT teams.
If your business analysts are trained and certified, they’ll know their own roles or can adjust quickly to what you want them to do. The agile IT team should be fairly self-directed. All you need to understand is who does what, present the responsibility chart and stand back ready to support them if needed.
Agile teams do not need any supervision or direction over and above their own ScrumMaster, who is 100% devoted to one project at a time. Ask your BAs if they will cross-train as ScrumMasters to maximize the number of projects you can run at any one time.
Due to the new strategic and business requirements from PMI, project managers have now been renamed. Just have your newly christened business analysts do what project managers have always done.
If you are a traditional project manager practicing agile methods, chances are you don’t really “get” it. Nothing has been worse for the understanding and proper application of agile approaches in organizations today than the flawed thinking and actions of well-meaning middle managers and project managers.
This is the first in a five-part series of articles regarding agile frameworks based on values, principles and practices. Scrum espouses five values: courage, openness, respect, commitment and focus. In this series, each article will explore one of these values--on which a deeper discussion of principles and practices assembles.
In the last year or so, this practitioner has seen an increasing number of project management job postings asking for agile experience. What’s driving this trend? Is this something project managers need to be aware of when considering their career development?
The purpose of this article is to guide project managers in implementing an earned value management system by following ANSI/EIA-748 guidelines in a manner consistent with agile software development methodology.
by Kevin Aguanno, CSPM (IPMA-B), Cert.APM, PMP, PMI-ACP, CSM, CSP, FPMAC, FAPM
Agile encourages project teams to work with the sponsor to understand the greater context surrounding the project. With this broader understanding, the team can look for ways of structuring the project to improve the chances that the business will actually achieve the business case benefits.
Project management tools are getting more and more sophisticated as they compete with rivals on features and spread to support more platforms. Yet sophistication has a cost. Let's explore how a combination of deliberately low-tech inputs and outputs can be used with modern tools to deliver the best of both worlds.
When teams transition to agile development and the QA/testers continue to follow the same testing processes and tools they used before joining the agile team, you're asking for trouble. In this article, we contrast agile and traditional testing--and give an example of how a mind map can facilitate the testing process.
When large enterprises are trying to embrace DevOps principles for their ERP transformation programs and similar other packaged software implementations, how should PMs running these projects tailor their traditional project management principles to adapt to the new philosophy?
Organizations often talk of project management failure and put us in a vicious cycle of cause/effect analysis loops. The problem is that we look for the cause of project management failure where the light is--and not in the dark spot where the true issue is. This three-part series helps to uncover some key underlying and recurring sources of confusion within organizations. Part 1 looked at decision-making dilution; we now turn our attention to methodological and structural confusion.
Portfolio management is responsible for translating strategy, changes, innovation and dynamism into value for an organization. To achieve portfolio agility requires synergy in all aspects of the enterprise: in the strategic environment, in the portfolio tactical environment and in that of the projects.
There are many different reasons why people will do the right thing to help you build and maintain the momentum for your change initiative and to help you achieve sustained, collective momentum. The key to building and maintaining momentum is to understand and harness the different mindsets that cause people to choose change.
These days, it takes more than project management skills to succeed. It takes a person with agility—flexibility in understanding and applying the ins and outs of any method. Let’s investigate what "hybrid PM" is all about!
Hybrid project manager roles might be the way of the future. Do you need to revisit your skills? This article provides guidelines to assist you with becoming a hybrid PM, and starts by defining their characteristics.
When a project requires an agile delivery model but the organization is tied to strict waterfall methodology, the team needs to be creative in order to meet its goals using all of the tools in the project management tool bag. Read the story of a team that learned that agile and waterfall can (and, indeed, should) co-exist to provide outstanding results.
New technology projects carry a high degree of uncertainty. Agile promises to manage uncertainty. Does this make for a natural match? Or are there more factors that influence the project manager’s chosen approach to a new project?
Agile teams bring both challenges and rewards, and the rewards don’t happen at the click of a finger. Leadership is required. Here, the author shares four strategies and his favorite techniques to help teams graduate from storming.
The risk we take in swearing allegiance to a specific approach is that following the approach often becomes more important than achieving the goal of the project. Let’s explore the merits of using the best of different approaches—and how marrying them into a hybrid model impacts the way projects are planned and managed.
If you have not run a hybrid project leveraging agile and waterfall methodologies, you are in for a great learning experience. Let’s put the two distinctively different approaches into a broad and high-level context…
As hybrid projects become more common, what has to change among team members, and how do we manage that change? Do we have to minimize these disruption scenarios, or can we create an environment where teams are more comfortable with the shifts?
The best agile software teams communicate well, push hard to meet deadlines, support each other when struggling with issues, and go above and beyond to maintain quality. The key element is trustworthiness. In this article, the writer provides a self-assessment tool that will allow you and your team members to assess and demonstrate trustworthiness over time.
Question: We have switched to agile practices and, if I do say so myself, I think we are doing an awesome job. However, even though we are carefully creating backlog lists and writing user stories, more often than not our end product or service still does not meet the expectations of our internal and external customers. Has something been left out of what we were taught?
Agile does provide a way to use non-functional requirements in its methodology, but often it is overlooked or not stressed when new teams are preparing their first few projects. Make a point to add them into your new process.
The reason agile projects are completed so much faster and provide so much more value is that with the Scrum practice methodology, it is no longer necessary to consider vague things like non-functional requirements. If they aren’t going to function anyway, why bother with them.
User stories are only written if there is a need for outside personas to be created to represent users. Non-functional requirements are the ones assigned to those personas who would not be interested in your product or service, and therefore can be excluded from consideration.
Many projects have both functional and non-functional requirements that impact the outcome of the project. That is why only traditional processes should be used. Agile processes work only on software projects, and then only when there is an absence of non-functional requirements to be considered.