Suppose you have a number of products, or a number of applications, that share some common functional needs. It seems obviously reasonable to create a separate team to build those functions in common. Often these grow to become known as a framework, and the product or application teams are expected to use it.
It’s a seductive concept, but don’t do it. Why not? I can think of several reasons. Read More
Adding a new team member to an existing team always introduces challenges. The introduction changes the makeup of the team, and if the team had jelled, it has to do so, again, with the new member.
Also, the new member has to learn about the team and its work. There are many tacit assumptions held within a team. It’s impossible to document them all and, even if you could, both reading such a document and keeping it up to date are daunting herculean tasks.
So how do you maximize the integration of a new team member with a minimum amount of work? Read More
A common question heard in companies that produce software, either for in-house use or for sale, is “When will this software be done?” I’ve observed this question being asked when it was not yet decided what the software was to include, nor who was to build it. It’s clear that we have little on which to base an estimate, given this state of affairs. Nevertheless, in many organizations, people will start to anticipate what it will include and who will be available to build it in order to give an answer to this question.
Not everyone is so compliant, though. Some people will say that not only can you not estimate the construction with so little information, but you don’t need to estimate it. They’ll say it’s enough if you can build it in little increments of functionality, and stop when it does enough. Read More
My article, “Project Communication: Caught in the Middle” has been published on projectmanagement.com now. It talks about the communication issues for a project manager in charge of an Agile project, and ways to manage both downwards and upwards.
(Free registration required)
I’m working with a client that has multiple, non-collocated component teams working on one project. It’s not my ideal situation, but we’re making the best we can of the situation.
We built a story map of business-oriented, project-level “epics.” These have been prioritized within business themes, and have been tentatively scheduled for development releases. The early ones have been estimated with level of effort (LOE). Basically these LOEs are Small, Medium, and Large, but given numeric scores to allow tracking project progress toward development releases from a business point of view using a burnup chart. Read More
I’ve achieved some notoriety with my Test Driven Development hat. Not so much when I wear it
, but certainly when Uncle Bob does. So much so that he has received queries about acquiring or making them. Read More
I’ve talked about the rush to standardization before. This article offers a more detailed look at the problem, and offers an alternative.
In my experience, Agile projects almost never have a single milestone at the end. The business wants to see multiple milestones along the way, taking internal releases from the development team even if they’re not prepared to make them public. The simplest dashboard I know to illustrate this situation is a burnup chart with multiple goal lines, indicating the goals of each milestone.
This sort of chart is trivial to create by hand or with a spreadsheet. The typical Agile Project Management software, while providing a myriad of ways to view data, never seems to include something as simple and powerful as this. Fortunately, it doesn’t take much time to create your own. It takes a few minutes at the end of each sprint to update the chart, and you can make sure that the data is correct as you do so.
A common complaint against Test Driven Development is that writing tests and refactoring take too long. In the long run, I’ve found that TDD has improved my skills such that I can complete work faster by writing tests and refactoring than without. I’ve also found that this information is a weak argument for those who have less confidence in their skills, or feel too pressed for time to learn. But that’s not the only benefit. Read More
A lot of people and organizations, when transitioning from a serial software development lifecycle toward an Agile one, fall into the pattern of mini-waterfalls. They start doing iterations, but each iteration resembles the development lifecycle they already know. The programmers do some design work, then they write the code to implement the design, then unit test the code, and then they pass it to the testers for testing. To many people, this is the only way it can work. Their mental model only admits to this series of phases.
And they run into typical problems. Sometimes the design doesn’t fit the problem well, and patches are needed because there isn’t time to go back to design. The testers get squeezed for time at the end of the iteration, and no one knows how to accommodate the rework when a problem is found. More patches are added, because there isn’t time to redesign. And the next iteration starts the cycle over again.
Sure, doing this in two to four week cycles beats doing it in six to twelve month cycles. But only a little. Most of the time, it starts to fall apart if the team doesn’t learn to work differently.
But it’s inevitable, they say. Read More