Let’s say you’re planning to repaint your living room this weekend. You shop for supplies online: drop cloths, painter’s tape, and brushes. Alexa, innocently, puts scrub brushes in your cart instead of paint brushes. The delivery arrives the next day. Do you have the tools you need to get the job done? The scrub brush has a handle and bristles! The bristles can be dipped into the paint! Will it require more work to create the desired outcome with a scrub brush rather than a paint brush? My guess is, no matter what, it’s not going to be pretty.
It’s not that the scrub brush is a bad product. On the contrary,
it’s probably the highest rated scrub brush on the web. The issue is that you
need a paint brush specifically designed to apply paint evenly and precisely.
You need the right tool for the job.
Flash forward to the work week: How often are we using the
wrong tool for a job? (more…) Read More
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
Have you participated in or led a digital transformation at your organization? Was it really a transformation, or was it perhaps just a series of initiatives that sounded nice, felt good, and checked a few boxes?
I’ve seen many executives who’ve tried in earnest to digitally transform their organization, but were forced to settle for a set of random projects that don’t truly qualify as transformative. I’ve also seen some well-meaning but misguided initiatives fall short of embodying an effective transformation.
Sorry to break it to you, but swapping an analog clock for a digital clock in the lobby does not qualify as a digital transformation. (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
With all the hype around Agile, I feel compelled to state the obvious: not all IT projects are Agile. (And not all should be—although it’s easy to get that impression from Agile champions!) A waterfall approach is still a viable option for many IT projects. (more…) Read More
As any good manager knows, a team infused with a strong sense of responsibility will produce a higher quality outcome. Instilling ownership across a team is more an art than a science. It is a transformation that requires a deliberate communication style, some leadership savvy, delicate execution, and patience. (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
Many organizations try to fight against project failure by adding budget, resources, or time to the baseline. However, throwing money at the situation often leads to wasted efforts and more frustration, if the root problem isn’t addressed. Failure itself isn’t necessarily something to resist (see our thoughts on failing fast). However, pulling the plug on a major project can be easier said than done. Internal politics or other factors may limit the team’s ability to admit failure and cancel an initiative.
When your project is destined to fail, but abandoning ship is not an option, a brief pause and shift can allow you to turn things around before you completely blow the budget.
(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