Detailed schedules and beautiful Gantt charts might stop the screaming for visibility into your project, but they won’t help you sleep at night. In the back of your head, you’re waiting for the binky to fall out—for the project timeline to slip—and everyone starts crying again. Here’s how to break the habit of leaning on these common IT project management crutches.
Almost 30 years ago, when my wife and I were proud and exhausted new parents, we found that pacifiers would help our newborn twins sleep. This strategy worked for a little while, but when a binky fell out of one of their mouths, they cried. One of us would get up, put it back in place, and enjoy a few more moments of rest until it fell out again. We always say that one of the things we would do differently as parents is to have not used pacifiers. The boys became dependent on them, and they only postponed the inevitable.
Binkies remind me of how IT teams often use detailed timelines
and project plans. (more…) Read More
During a sprint, many Scrum teams focus on action items, story points, ceremonies, and sprint length. They often overlook the importance of the sprint itself to the team’s potential productivity.
Sprints are relevant to performance because a team’s effectiveness evolves over time, and a sprint is a block of time—each usually 1 to 4 weeks in duration. With each sprint, team members participate in Scrum ceremonies and deliver work together. The ceremonies alone don’t turn a group of strangers into a team, but they can serve as shared experiences that help members feel more and more comfortable with each other. (more…) Read More
An important distinction between Agile and Waterfall methodologies is how far out you plan. In Waterfall, you need to plan out the entirety of the project. This approach works beautifully for known products of understood scope. But when a deliverable is complex or has many unanswerable questions, Waterfall tends to fall apart, because there’s no way to do a sufficient amount of planning.
On the other hand, Agile thrives when products are complex and filled with unanswerable questions. With an Agile approach, you plan for only the next iteration—usually just 2 weeks. Agile works not because it avoids planning (Sprint Planning is one of the critical ceremonies, after all), but because it constrains the amount of work that you try to plan.
The idea is to reduce the total scope of work to a well-defined set of user stories. Each user story gets an estimate; the estimation metric is called a Story Point. (more…) Read More
Agile is about empowering teams and individuals. The roles defined by Agile are: Product Owner, Scrum Master, and team member. Not listed? Project sponsor.
That said, organizations often have established practices around designating a sponsor or two when a project or program is initiated. How do these two worlds meet? Should Agile teams have sponsors or not? Can a sponsor provide value to an Agile project?
(more…) Read More
Trust is the grease that keeps a team running smoothly. One of the most effective and low-cost ways to improve the delivery, performance, and morale is to gain the team’s trust. As a Scrum Master, it’s your responsibility to build trust with your team. A team that trusts their Scrum Master has an advantage over others. Broadly speaking, teams perform better when they feel they’re in good hands.
Scrum Masters can seem like outsiders, as you tend to interact with the team, not with their work. The dynamic is exacerbated during Agile transformations: Scrum Masters who are brought in to work with a team that is used to a waterfall approach can struggle to gain the team’s trust.
Here are 5 ways to connect with your team, and demonstrate that you are here to help and support them:
(more…) Read More
The Agile methodology has been widely accepted and implemented in many organizations for various goals. Most use Agile for project execution and product development. We even advocate using an Agile-based iterative engagement model for vendor management to minimize the risk of getting locked into long, inflexible contracts, and to prioritize outcomes over arbitrary task lists.
Many executives still think an Agile methodology would never work in their organization. Some have even attempted to implement Agile and were not happy with the results. Agile flops tend to fall into one of two categories: The organization either did not implement the actual Agile methodology, or was not ready for it.
(more…) Read More
We are big believers in an iterative model for vendor engagements. It’s a novel concept for some organizations. To determine if the approach is right for you, familiarize yourself with the potential risks and rewards for both the client and the vendor.
(more…) Read More
Agile is now being used far beyond its original purpose, which was software development. We see organizations apply Agile methodology to any project or program where the end result is a continual work in progress.
Come to think of it, my son and I use an Agile approach when we go fishing. We know we want to catch a bunch of fish, but we don’t know what kind or where, so we move our canoe around the lake all day based on our success in each spot, wind direction, time of day, and other factors.
Abraic exercises an Agile approach for our internal innovation program. Our R&D group is working strictly on a high-frequency, trial-and-error basis in one-week sprints. This minimizes cost exposure and allows us to make adjustments based on the latest findings.
Another area where an Agile approach is very effective is vendor engagement. The predominant practice to date has been to take an ambitious high-level scope and hand it off to a chosen vendor by means of a complex, long, and expensive contract. Yet, there are many cases when the project requires a significant redirection, including changing the vendor, utilizing in-house resources, re-scoping the project, putting the effort on hold, and so on. We end up having a to make a tough choice: make minor tweaks and complete as planned even if it doesn’t match our expectations or try to renegotiate – a lengthy and painful endeavor that may involve legal and oftentimes damages relationships.
(more…) Read More
“Culture eats strategy for breakfast,” is a famous quotation attributed to the late business management guru Peter Drucker. While a debate continues as to whether Mr. Drucker actually said it, the statement itself merits further exploration. I believe it means that any great strategy regardless of the depth of research, hard work, number of paid consultants, and even its own brilliance, will not achieve its intended future state if it fails to take an organization’s culture into consideration.
For part three in my Agile journey series, I will examine the importance of addressing cultural elements to achieve a successful Agile transformation. (more…) Read More
The promise of Agile is speed to market for delivering incremental value to the customer, but why is the adoption of Agile in organizations so difficult and slow? As addressed in my recent blog post, “Are you Using, Doing, or Being Agile?” Agile adoption takes more than just checking boxes, but rather is a complex, multi-phase journey. And any unfamiliar journey requires the navigator to know the destination. Have you tried using GPS without entering an address? Understanding where you are headed is a key component of any successful endeavor. (more…) Read More