tl;dr Codifying your process is useful as it guides others who come after you, but it may give them the impression that they're using your process and therefore have no permission to change it. It may even leave them arguing over the detail of what you really meant rather than thinking for themselves. I was … Continue reading Codifying or Ossifying?
Last year, I attended a training course for my company's chosen brand of agile framework: DSDM. I had some misgivings, having seen some bad projects using this methodology, but I was prepared to give it the benefit of the doubt. Long story short, I was persuaded of its usefulness*. To briefly summarise, if Scrum is … Continue reading Who needs DSDM?
I was recently tech lead on a 4-5 month project with some familiar team members and some new ones. The customers were internal users who have a fair amount of project experience. Early on, the project manager and I agreed to try and do it without sprints. Our reasons were diverse: Work did not seem … Continue reading To sprint or not to sprint
Everyone on the team should understand and be able to suggest changes to the team processes because developing great processes isn't the preserve of experts or coaches. We are often presented with a world of experts. Arguments about some subject or other are perceived to have been won by one side and lost by the … Continue reading Agile essentials 7: Own your own process
One of the risks of iterative development is that the pace becomes too fast for everyone to sustain. In this post I discuss why I think this is a risk and some things I've tried, or considered, to deal with it. Giving a team the time to do a good job is essential. I wouldn't … Continue reading Agile essentials 6: Sustainability
Only build stuff when you need it. Make decisions as late as you can. A decision isn't final until you have finished building whatever is based on that decision, and even then.. The principal that you should only build something when you need it is kind of obvious. For one thing, if you aren't going … Continue reading Agile essentials 5: Just in time
Agile teams are multi-disciplined and communicate closely, which avoids miscommunication, builds trust and makes sure that things happen quickly when they need to. If your team isn't working like that, you need to find a way to deal with it or any Agile processes you have will struggle. In my first tech job, an operations … Continue reading Agile essentials 4: Teamwork
The success of your project relies on you getting feedback on every aspect of your project, as often as you can. In a perfect world you'd be getting qualitative and quantitative feedback, but any honest feedback is better than none. When you get feedback, do something with it. I've been waiting ages for even a … Continue reading Agile essentials 3: Feedback
Trust isn't just an Agile essential, it's an essential whatever you're doing, but I think it is a good indicator of how successful your Agile practices are. You can't force people to trust you but you can do some things that will prevent them from trusting you. This post is about why it's important and … Continue reading Agile essentials 2: Trust
Agile essentials 7: Own your own processI'm not a huge fan of orthodoxies and methodologies, but they have their merits. Agile is a mindset. I argue that if you put the mindset first then you are in a better position to judge the performance of a methodology in your team. I go on to define … Continue reading Agile essentials 1: Agile, but what kind?
