One of the questions I've received in the past about agile techniques is how to ensure you've captured enough detail about your requirements in order to proceed without missing major scope elements.
When you create a standard business, it is deceptively easy to create one legal entity with shareholders, appoint a top manager, form a management team, and a hire a truck load of employees to be bossed around and do all the work.
I found a new Ted Talk on agile methodologies applied to family life. I've actually read about many families who do this and I've even met a developer who does this. He used Scrum in his own home. Now this little movement is getting attention in the form of a Ted Talk. Watch it here...
Half a year ago I wrote a blog post about 7 Agile Sins. As I’m sure that I’m not the only one who is guilty for one or more of these sins, I collected a list of possible ways to show penitence and to do it better next time :) So here is my list of the sins and their appropriate penitence.
Together the principles and practices we follow help us make the right tradeoffs so we can build the best system within the constraints we must work in.
Agile methods depend on effective cross-functional teams. We’ve heard many Agile success stories…at the team level. But what happens when a product can’t be delivered by one team? What do you do when the “team” that’s needed to work on a particular product is 20 people? Or 20 teams?
One of the traps people fall into on teams is withholding information that’s critical for the team to function. Sometimes the information is about friction between team members. When team members don’t have a way to talk about small frictions, they turn in to big events, damage relationships and spill over onto the team.
A Scrum Master is not a project manager. A scrum master does not manage risk by him or herself. A project manager will take on the risk management responsibility without asking the team.
"Put a good person in a bad system and the bad system wins, no contest.” It was amazing how quickly people, whose day job is to control actual important business numbers, lose focus of the same numbers (chicken-related, but important all the same) and their meaning.
Now I’ll admit, when I first heard this argument I thought “Well I can guess where they are coming from” - I have sympathy with the argument, I’ve always considered story points as suspect myself. I also thought “But I don’t think they are right”.
Martin Fowler wrote a prescient article about the rise of Flaccid Scrum. Having recently worked on an agile project that could act as Exhibit A for Flaccid Scrum, I have hardened my opinion on Scrum to the point where I believe that Scrum cannot succeed without XP-style technical practices.
Martin Fowler recently asked me via email if I thought there might be a relationship between Agile Fluency and how teams approach estimation. This is my response...
The best way to advance your agile journey is to get plugged in with others who are doing it. Here is a quick list of local and virtual communities, where you can find other practitioners like you.
This post helps you use your product demos as an effective agile market research tool: to collect relevant feedback in order to validate your ideas and improve your product. If you employ your demos to sign off user stories then this article will show you how to get much more out of them.
It's easy to see how people turn their angry glares towards estimation. This leads to an increasing notion that anyone indulging in estimating is an Not a True Agilist. I don't share this view of estimation as an inherently evil activity.
Fighting procrastination is a never-ending battle. It takes many forms and the pomodoro is a weapon to combat it's many shapes. I last wrote about pomodoros about a year ago and it’s interesting to see that I’ve covered almost completely different things than I did last time!
If you want to organize an agile program, so you can manage the stream of features in your agile program, you have some options. It depends on the size of your program. The communication structures in your agile program matter.
Or more accurately, the inadequacy of the after-course evaluation process to gather meaningful and actionable feedback.
I’ve been keeping a little list and there are 11 reoccurring myths. There are also two truths which are a bit more difficult for teams and companies to accept.
If you want to release your code frequently, you have to automate the release process. If your software interacts with shared components or other applications, the release script may have to update shared configuration files.
Distributed and virtual teams are a reality of today’s world. It is not just limited to well-heeled MNCs – we see countless everyday examples of such teams with NGOs, startups, voluntary efforts, college project and so on. This four-step process has served me well in multiple scenarios.
A few days back I saw the presentation from Netflix about its culture, and three interesting slides from it was about what drives talent out of a company.
It seems that we have now entered a phase where Agile is accepted as the default and now instead of everyone trying to pitch the idea of Agile, everyone is trying to fix their broken Agile implementations.
If you want to release frequently, a problem you may encounter is that some features, even though functionally complete, don’t stand well on their own, but require other features to be valuable to the user. A Feature-on/off-switch is a simple idea for dealing with this.
That’s right, when you go to change an organization for the better, you need to do the culture part last. You can NOT change a belief system, until you first have some positive behavioral evidence.