Technical debt describes the cumulative consequences of cutting corners in software development, but it escapes the attention of many project managers as they focus on scope and schedule. That’s a mistake because it impacts both. Here are questions to help you ascertain the real state of technical affairs.
Transitioning toward Scrum practices isn't easy for every team. I've used a visual image that I call the Scrum team scorecard to help. It's a one-page "snapshot" of the level of transformation of a project team into a Scrum team. An independent o...
There’s going to be a lot more talk about Agile now that the Project Management Institute has introduced a new certification program for Agile Project Practitioners. Let’s clear up some initial confusion and look at what Agile is and is not, and why you should care.
Organizations and teams must come to understand why they need agile before choosing a methodology or tool to implement it. A mandate alone will not work. It is the overarching goals, values and principles of Agile that must ultimately guide teams in the adoption and adaptation of its practices.
In the software industry, professionals hold different views on processes. Some say processes are bureaucratic and rigid, making their lives difficult. "Why in the world does a simple software installation have to go through X number of approvals when I have such an urgent task at hand?" Others (mostly members of organizational process groups) relentlessly endorse standardized processes and talk about how the organization could be benefited by the data collected from following those processes. Project teams, though, are often unconvinced, since what the data says and what the customer says can differ.
Projects, projects, projects! You know you don't like them, but do you know why? Is there a better approach? In this article, I'll outline why we've chosen to be project oriented in the past and why pulling "the Big Lever" toward release orientation is so important in making the move toward Agile solution delivery a real success.
Scrum and other Agile methodologies rely heavily on a set team structure to succeed. In Scrum, you have a team, a ScrumMaster, and a product owner. These teams work on features that are iteratively developed. As explained by Mike Cohn, the teams are commonly called "feature teams." However, quite frequently...
When I set out to practice and preach Agile methods, the world looked rosy to me. A team built on qualities that are human made much more sense than a team kept together by command and control. A team where everybody valued each other's individuality and uniqueness yet functioned toward one goal in an orderly manner seemed possible.
But at the runway, I realized I didn't have any wings. Why? Because stakeholders were yet to come out of the comfort zone of spreadsheets, where command and control made a lot of sense.
We all start our learning process from our own native-language alphabets. Similarly, I have attempted to create an Agile alphabet (in English) for helping new Agile enthusiasts begin their learning of the common vocabulary. This is not a bible or dictionary of Agile terms; it is a knowledge base. It can always be enhanced to achieve maximum satisfaction and an Agile match-up to the alphabet.
"When will you deliver the project?"
"How can you ask that question? We are Agile!"
"At least give me a high-level timeline. When should I expect the release?"
"In the future."
In other words: How do we schedule timelines for a project or a product in a complex environment where the outcome of one team is required for the other teams to start their work?
Ours was a typical Waterfall team that believed to the core in the SDLC (systems development life cycle). Our requesters were always adamant about sending countless changes to us at all stages of the project flow. This led to a lot of rework, a de...
"Cheng, this is just a three-point story. We shouldn't take more than 30 hours to do this," one of the developers told me during the sprint planning. And a development manager once advised me, "Cheng, you must not pull in any other stories, becau...
I was playing Rummikub with my kids and noticed they were unnecessarily frustrated all the time. In between their own turns they spent the whole time moaning, "You've ruined my plans!" every time another player put a stone down. It was not a new ...
After years of helping organizations large and small to transition to become more Agile, I have learned one thing: The larger the organization, the more Lean thinking helps to be effective while using Scrum. Lean is not as necessary for smaller organizations with independent teams; however, it is vital for larger development organizations, say of 100 or more. If you work in a larger organization, this article is for you.
I owe the title of this piece to Alistair Cockburn, who several years ago wrote a favorite article of mine for Cutter IT Journal entitled “What Can We Do About Our Project Managers?”# I think it remains a relevant read today. In it, Al...