Question: In our attempt to move to an agile-driven organization, management has asked my team to be involved with responding to a proposal that, if we get it, could provide an increase of 50% in our gross income this year. Since we’ve always complained that we weren’t consulted before contracts were signed, now the pressure is on for us to be very wise regarding what we add to the company’s submission. Are there any rules of proposal development for agile teams?
Yes. Just like rules for creating speeches can make the difference between wowing the crowd and expounding to a bored audience, learn the correct way to write proposals. Hint: It is better to win the business than look good and have a fancy document.
Yes. Many colleges and universities have degrees in contract writing. At least one person on the team should have at least 12 hours of formal education before you include the team’s ideas in the proposal. The good thing is that this training can also be used for PDUs.
No. Those who become skilled in contract negotiation and responding to proposals are housed in a special procurement department. They have eked out their skill sets through years on the job. While you can sit in on meetings, don’t risk looking foolish. Always defer to their ideas and decisions.
No. There is so much political intrigue and price fixing involved in Request for Proposals (RFP) or other versions of how organizations solicit bids that not much depends on the actual proposal submitted by your organization. See if anyone on your team knows anyone in the potential customer organization who could leverage the decision to your advantage.
Agile projects may look like untethered pinwheel rockets spinning away on unpredictable paths. How do we align them to IT strategies so they don’t adopt all kinds of crazy technologies the organization has to support or replace?
In the first article in this series, we looked at some of the links between agile and change methodologies. In this article, we will investigate a different question: Are you and your organization ready for change?
There’s a lot of talk about strategic or enterprise scale agile, but what do organizations have to do to prepare for such a change? The right approach will depend on the needs of the organization and its willingness to absorb change.
How fast is your organization capable of changing to continue to remain relevant and successful in the marketplace? The world is changing at an accelerating pace. Companies are rising to global scale faster, while large, successful companies are disappearing faster--leading to the need for agile change.
The organizational world within which project managers operate is going through rapid and unprecedented change, driven by forces of globalization and digital technology. So, the choice is yours: change now, become PM 2.0 and survive. Don’t change, and await extinction...
The alternative to embracing change doesn’t have to be completely rejecting it. Are there ways we can introduce more flexibility to waterfall projects without losing control of change? Can traditional project execution approaches learn anything from the agile approach to change?
Project management in construction follows traditional planning methods to communicate project schedules. The objective of this article is to show how agile tools like burnup and burndown charts help communicate project timeline and progress.
Agile methods recommend co-location and face-to-face communications, but studies of office workers show high levels of dissatisfaction with open-plan environments. So, how do we make agile work and minimize the issues surrounding open-plan environments?
Is agile working for your team? Do standups feel like micromanagement? Are people missing commitments because they are spread across projects? If people are going through the motions of agile and aren't happy about it, use these five key questions to help.
Kanban has become popular in the software development world--but is used very selectively. Developers are missing real opportunities to better serve customers in both software operations projects and in new development projects. Here we cover the core principles of Kanban that can be applied to any project where improved quality and throughput are desired.
You’re a hardworking, successful business analyst (BA), and have just been told your organization is “going agile.” Perhaps you’ve heard a few details about the types of roles involved in an agile development environment, but nothing that really depicts how a BA fits into this new atmosphere. So what does this shift in your organization mean for you?
by Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP
The number of agile certifications available in the market keeps growing, and one must consider the unique needs of the inquiring company or individual to know what would be best for them. What factors should you consider? Do you even know the options available?
Managing quality during a software development project can be difficult and time consuming when you have been misinformed about true quality indicators and practices. Actively managing quality on an agile project can be both simpler and harder than traditional approaches. Here are some basic practices to save time and unnecessary rework--and improve stakeholder satisfaction before and after delivery.
Project managers need to communicate effectively with all types of project stakeholders. For agile projects, this sometimes involves adapting traditional PM constructs into the closest agile alternatives. Agile pendentives are adaptive patterns that facilitate these traditional-to-agile discussions.
Agile approaches often have greater engagement levels between stakeholders. While those conversations generally focus on the deliverables and how they meet the customer’s needs, can they also drive sustainability best practices?
Agile does not enforce rigid processes, but organizations typically choose a guiding framework and a set of practices that serve as the starting point of an agile transformation. Executives typically want to know where teams are in terms of adopting these new ways of working. This article provides three techniques--individual, team and group--that can be used to assess the agile adoption level, monitor progress and drive improvements.
How many of us start a project thinking that we understood the reason behind doing the project in the first place? There’s about half of us who never aligned the project’s mission with the overall department or company vision, resulting in poorly made decisions--and possibly a breakdown in team morale. Providing a project focus that supports a larger purpose is particularly important for fast-paced, adjusting agile projects.
Some people see agile projects as knowledge transfer deserts where information is hoarded by key individuals and no useful documentation produced. Others believe agile projects are all about knowledge transfer. So why the disagreement? How can smart, experienced people have such different views about the same topic?
Have you ever entered a sprint taking on a user story that you later regretted? What can be done to prevent this frustration? Is there a technique that will prevent this from happening, or are these teams doomed to keep repeating their mistakes?
Question: After a recent conversion by my team regarding agile, we find that there is a mismatch between the number of hours we should have for working on stories and the amount of time we really have. So we are constantly over-committing to our Product Owner and not delivering. Where are we going wrong?
Traditional teams may have a 15-20% contingency cushion in time and cost on their project estimates. Routinely subtract a similar agile contingency from the number of backlog items you accept to make sure you finish all planned work within a single iteration.
Agile is expected to be flexible, and velocity can vary. Just complete what you can and adjust your velocity for the next sprint if you don’t finish all of the stories you committed to complete this time.
Be sure you are acknowledging hours that team members will spend in Scrum ceremonies, personal time commitments and non-team directed organizational work before calculating the capacity for this iteration.
Ask the ScrumMaster to speak to anyone on the team who did not finish his or her work during the previous iteration. This person is making the team look bad and should be disciplined if it happens again.
A retrospective is a special meeting during which the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole-team learning, act as catalysts for change and generate action. This article presents some of the reasons why the retrospective’s efficacy can fade over time and then discusses some interesting techniques to keep them lively.
We are ready for any unforeseen event that may or may not occur.