TDD Hat
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
Coherence vs. Standardization
I’ve talked about the rush to standardization before. This article offers a more detailed look at the problem, and offers an alternative.
Multi-Release Burnup
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.
Rough Cut
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
Avoiding Mini-Waterfalls
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
Coaching Conversations: Organizational Values
A video of a conversation I had with Esther Derby, Geoff Watts, Maria Mastarelli, Susan DiFabio and David Koontz at Agile 2012 has now been posted on the Agile Alliance website. In this conversation, we talk about organizational values and how that impacts organizational behavior.
Unintended Demotivation
Are your well-intentioned actions having consequences you don’t intend and don’t want? Read “Unintended Demotivation,” my latest article on Gantthead (free registration required).
Also, I don’t think I ever announced my previous article on Gantthead, “Better Success Across Large Projects.”
Agile Fluency
Diana Larsen first told me about the Where Are Your Keys language learning game that Willem Larsen and Evan Gardner were playing in early 2009. I was initially intrigued, but when I experienced it with Willem later that same year, I became enthusiastic. My interest lay not in learning languages, but in applying the same techniques and framework to teaching Agile techniques. I immediately began thinking how to make that application, and I’ve been thinking along those lines ever since.
Thus, it was with tremendous expectations when I saw that Diana and Jim Shore had published Your Path through Agile Fluency on Martin Fowler’s website. Having read it, I’m both greatly encouraged and slightly disappointed. Read More
Bad Scrum, but Pretty Good RUP
Most metals have a bit of springiness to them. If you want to bend them to a certain shape, you have to bend them further than that. When they spring back a bit, they’ll take the shape you want.
Today, I was looking at a milestone chart for a project transitioning from a serial lifecycle to an Agile one in a large organization. At first, I despaired at the picture it painted. There are Requirements and Design phases for the release, and a “hardening sprint” before release. Don’t get me wrong. Things are much better than they were before the transition started, but there is quite a way to go before this effort reaches what I would call truly Agile.
Then it struck me. Read More
Component Stewards
I’ve been an advocate of using feature teams instead of component teams for a long time. Back in the 1980s and 1990s, when I was working on embedded systems using 8-bit microprocessors, I often did both the hardware and software development. The easiest way I found to work was to develop both in parallel, adding complete functionality feature by feature. Working in this fashion also gave me great insight into choosing whether to implement a particular bit of logic in the hardware or software. Sometimes a software implementation could save a lot of expensive hardware, and other times a small bit of hardware could save a lot of software or provide better performance. Since I was working on both sides of the fence, I could easily move the logic from one to the other, sometimes changing my mind as I learned new information while implementing the functionality.
When working in larger teams, the work was usually split between hardware engineers and programmers. Occasionally I could influence a change in the hardware while working as a programmer, but not always. I really missed the ability to optimize across the hardware/software interface that I’d had when doing both sides.
When you scale up to large numbers of people working on a system, things can get out of hand, though. What happens when a lot of people make changes to the same components without talking with each other? Usually, the conceptual integrity goes out the window. So, what to do? Read More