Since agile is about individuals and interactions, it should come as no surprise that it helps with many talent management recommendations. But what do we do when HR recommends practices that are counter-productive to teams? In our concluding installment, we examine these six talent management strategies—and what motivates us.
When companies move to an agile Software Development Lifecycle (SDLC), they often remove the processes and analysis of their waterfall SDLC because, as the Agile Manifesto puts it, “They value individual and interactions over processes and tools.” Some of the rigor should be removed – waterfall processes can get bogged down with gates and sign-offs. However, caution must be exercised to not go too far against processes and analysis and rely just upon backlogs and user stories. Requirements and the analysis that leads to those requirements are just as essential in an agile project as they are in a waterfall project. The difference lies in how much requirements analysis is completed and the timing of it.
Have you noticed that as project execution approaches evolve, they become more Agile (or at least “small ‘a’ agile”)? Does that create opportunities for more formal acceptance of agile concepts throughout organizations?
Since agile is about individuals and interactions, it should come as no surprise that it helps with many talent management recommendations. But what do we do when HR recommends practices that are counter-productive to teams?
by Doug DeCarlo, Principal, The Doug DeCarlo Group
In today’s increasingly complex project world, more and more project managers are finding themselves riding an extreme project. Yet few possess the leadership skills, mindset and temperament to succeed. In this two-part series, we’ll outline what it takes to be a successful eXtreme project leader. In Part 1, we’ll cover the quantum mindset and contrast it with the opposite (Newtonian) mindset.
In an ideal world, a cross-functional Scrum team must be fully focused on Scrum. The team is also expected to hear a voice of one customer only: the product owner. But what happens when reality intervenes and you get pulled in other directions? As our two-part series concludes, we look at the remaining two ways of interrupting Scrum sprints--and share what can be done about them.
In an ideal world, a cross-functional Scrum team must be fully focused on Scrum. The team is also expected to hear a voice of one customer only: the product owner. But what happens when reality intervenes and you get pulled in other directions?
How can we bring about agility in an enterprise system that has existed for years? In this article, we look at an interesting concept introduced by Gartner in late 2014: bimodal IT, a solution for some enterprises to move from the slow lane to the fast lane.
A cargo cult occurs when people adopt rituals expecting some good behavior to occur. They really don’t know why they are doing these rituals and don’t understand the reasons behind them, yet they keep doing the rituals expecting great results. In this article, the author gives two contrasting examples: Project A talks the walk, Project B walks the talk.
Question: While I know that the retrospective step in the agile process is said to be important, I must admit that my team dreads these meetings. Is there a way to focus our time so that instead of silence when we are asked “what we could do better,” we are actually able to have some meaningful discussion? I know what we do each iteration is far from perfect.
If your team responds with silence when the ScrumMaster or team lead opens the retrospective meeting for discussion, it is because you have actually done an excellent job during the preceding iteration and there is nothing to be discussed or changed for the next one.
Perhaps having a list of questions that you follow in each retrospective meeting will give the team a focused way to evaluate what happened in the last week or weeks. Knowing the questions ahead of time may also influence the data people tuck away while it is happening, in anticipation of the next sharing session.
The difficulty with being honest about team failure during an iteration can be due to the presence of leadership or customers. Only the team itself should be allowed to attend the meeting. Then they are free to talk openly about the success and challenges of the project work, as well as the impediments presented by management.
A team responding to a retrospective opportunity with no comments means that the meetings are taking too much time away from the work of the project. Limiting this group discussion to no more than 10 minutes will free participants to quickly present their problems and walk away while the ScrumMaster or team lead solves them.
There are great opportunities for growth and deviation outside the standard agile models for stable teams who want to evolve further. This article tells the story of one team that did just that--and what other people can learn from it.
Information radiator is the generic term for any of a number of handwritten, drawn, printed or electronic displays that a team places in a highly visible location. It conveys the latest information at a glance. Learn how your team can foster collaboration through visible project management and implementing radiators.
By significantly reducing your number of parallel projects--focusing on fewer, and then trying to get them done--you might get better results. Why? Because multi-tasking is the enemy, and agile is a capacity equalization play.
by Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP
Project delivery organizations need more than just a bimodal approach. While waterfall and agile are very different delivery approaches, if you put them on a spectrum with one at each end, you will find that many projects would ideally be situated somewhere along the spectrum between those two extremes. Instead, optimal delivery would be achieved with a tetramodal delivery approach.
Adopting and maintaining an appropriate project methodology is vital for organizational success. The purpose of this article is to explore and analyze project methodologies that find common application in effective project management.
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?
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.
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?
Development organizations are often attracted to agile development practices with the promise of increased test automation to help their teams deliver higher quality faster. It’s not just any tests though: We look to automate the kinds of tests that provide rapid feedback to tell us if we have built the product right. But which tests do we automate, and when?
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...