Tag Archives: Agile

Agile Development: 5 Lessons Learned

Working in software development can be challenging and tricky without the right plan in place, especially without a plan that caters to your employees’ work styles. Here at SoftArtisans our development team follows the agile dogma and we’ve discovered several lessons along the way. Wondering if agile development is right for your team? See below for 5 things to keep in mind when implementing this work style.

1. You absolutely need backup from higher-ups.

Too often I have seen or heard of departments that were “going agile,” but management was not behind them. No matter how enthusiastic about it the developers were, their plans were ruined every time management expected something to be “like it used to.” Managers who don’t give things time to adjust create developers who don’t give things time to adjust, and then everything is doomed to fail.

2. Retros are vital.

One important thing about agile is that you can change things quickly when you need to. This applies to the direction the software is taking, but it also applies to the processes and mindsets of team members. This is what retrospectives are for. A good team will be able to be honest about what’s working and what isn’t and subsequently make changes for future sprints.
This whole process is much easier when…

3. Retros don’t include higher-ups.

Management usually wants to know what’s going on, and that’s great, but retros are not the place for it. Continue reading Agile Development: 5 Lessons Learned

Scrum Debates: Research as a Task

The concept of scrum can seem very simple in theory. As stories come in, the team analyzes them, and then story points them based on the complexity of the story. It couldn’t be simpler. But in practice, it is rarely this simple. The problem is that sometimes you won’t know just how complex a story is until after you’ve played around with it a bit. At my company, this is a problem we face almost every time we meet to story point backlog items.

Usually, a bit of uncertainty is fine. That’s the entire reason teams usually story point with a non-linear scale (one the popular scales being: 1,2,3,5,8,13,20,40,100). If a story could be anywhere from a 30 to a 40, then just give it a 40 (assuming we’re using the popular scale). Even if the story ends up closer the 30, there’s probably some other story that was more complex than its story point implied and it all generally averages out. But every now and then, there’s just too much uncertainty. A story might be anywhere from a 5 to a 50 depending on factors you won’t know until you’ve looked into it a bit and done some research. Continue reading Scrum Debates: Research as a Task

Scrum Debates: Story Pointing Bugs

Our company adopted scrum as our method for development over a year ago. And to this day, we’ve yet to get it entirely right. Over the months we’ve had to address issues ranging from “What do we do when critical issues come up?” to “Who should be a part of our daily scrum meeting?” to “What the hell is a story point anyway?” But one such problem that our Product owner recently brought up is, “Should we really be story pointing bugs?” And the answer, of course, is… well, actually, no one can really agree on an answer.

Well, let’s start out with why we all originally said yes. In any given sprint, our team will have to commit to some handful of stories and bugs off the top of the product backlog. If both the stories and bugs are story pointed to the same scale, then we have no problem deciding how much we can commit to this sprint given our previous velocities. And for a while, this worked fine.

But let’s look at this from the product owner’s point of view. Let’s say we’ve just released the next version of our product and now our product owner is looking over the backlog, trying to figure out how many sprints we’ll need to complete the required features (let’s say there are 10) we need for the next release. Each of these features gets defined as a story. For the sake of simplicity, let’s say they all have a story point value of 10, resulting in a total of 100 story points. In our past sprints, our velocity has averaged 20 story points. So our product owner can set the next release date for five sprints from now. Easy! Continue reading Scrum Debates: Story Pointing Bugs