A changing community...

I love agile. I've adapted it into my development and never looked back.

If there is agile, why is there ALT.NET?

The development environment of many institutions is molded to the vision of software provided by people with no insight.

Pushing irrelevant solutions and deadlines.

Traveling a rote technology line.

Where does that leave the rest of us?

We go with the flow.

We find a place that embraces agile.

We work to change our environment.

It takes a great deal of energy to foster change in your environment.

It takes time, effort, trust and many other qualities that make going with the flow look better and better as time goes by.

You are not alone.

Your company software policies were not created by your company.

They are the practices of the community.

A community that conforms to business and technology providers' desires and not the interest of creating the best solutions.

What is ALT.NET? It is a community that will not conform to these principles. It is a group that is working together to foster change beyond our individual environments.

What is the ALT.NET Open Space? It is for people who want change. It is for people who want to share. It is for people who want to learn.

Everyone will be someone who wants to do something for the community. They will come with something they know and leave with something to share.

More about → A changing community...

Scrum and the product owner

Oksana and I (do we ever do anything alone?) are in Boston for Scrum training with Ken Schwaber this week. The class is interesting; I know a lot about scrum and have been practicing (or trying to practice) it since 2003.

One thing that I kept reflecting on during the class, is the true value of the product owner.

Before Oxygen, I always lacked the single wringable neck. I met with stakeholders, had iterations, backlogs, daily meetings -- everything, but the true product owner. Most times, I would have buy in from users and developers to participate in meetings and monthly reviews, but I never had what I have at Oxygen and it was a flawed way of working.

There is a conflict of interest between the product owner and a developer. Yes, you share a goal, however, its the developers job to expose risk and estimate effort and the product owners job to evaluate the information to make decisions that will decide the fate of the project.

It wasn't until training today and working with people that didn't have the luxury of the product owner that I remembered the pain lacking one. I've been trying to write about this and I have no words...

Luckily, Ken did a few weeks ago, this is what I want to say. I really loved reading it when Ken wrote it; today I appreciated how lucky I am (once again).

More about → Scrum and the product owner

Depressing blog?

One of my fellow developers told me this blog has been depressing... making them feel that we aren't quite the snazzy agile team.

I understand why they feel that way.

In the spirit of agile, I write openly about our shortcomings. In many companies people are reprimanded or even fired for pointing out issues internally, forget about posting them publicly.

I would not show weakness in our agile group if I were not confident in our teams spirit, devotion, intelligence and adaptability. We all love and appreciate the agile practices and I feel very lucky to work with such a talented group.

Agile is a great tool, but its difficult. It takes effort. Its frustrating. Like anything worth doing, you have to work at it. And like anything you love, sometimes you write about why its so great and sometimes you need to write about why its so difficult.

More about → Depressing blog?

where do the bugs go?

Our 45/55 resource split (or lack of resources) has become apparent on our new product development. We spend 45% of our time on new product work (a very exciting WPF application, Ript) and the other 55% on internal enterprise work (to keep the tv station up and running). This split yields about 4 development days on Ript during each two week sprint .

We're all excited about Ript and want to share it with our friends and family. This gives us extra drive to complete the list of stories left for release!

This drive coupled with the lack of time has become evident in a recent spike in bugs and refactoring cards. The goal of the current sprint is stabilize the application, because we ended our last sprint with an unreleasable application. So, our burndown for the sprint included every known bug in application.

Our burndown looks something like this:
Sprint goal: Stabilize application -- fix 18 open issues
Bugs fixed so far: 26
Bugs left: 16 (I told you that last release was unreleasable!)

Because our goal is stabilize the application, we're treating the bugs as stories and adding stories to the sprint as bugs are found.

How did we get here? We are all profession, strong developers who are very committed to quality...

What went wrong?

Well... we've been "finishing" stories when they aren't really "done."

This isn't happening because we are lazy or over worked or don't understand the requirements, but because we are so desperate to move forward in the project.

When you have a 2 week iteration, even if you don't spend all 2 weeks on the project, you want to finish 2 weeks of work. Especially after a few weeks of enterprise work that take up more than 55%...

Enough explaining why we have bugs...

What was this post about anyway? Oh yeah... making bugs stories...

I had an ah ha moment the other day when I was thinking about where bugs belong in the sprint backlog. As a developer and a user of an application, I don't want any bugs. Our customer proxy may want features before bugs are fixed, but we may want to fix bugs before adding new features, because the bug could be a smell of a bad design or some needed refactoring... basically prioritizing bugs difficult!

Have you seen this bug rating system before (or something similar)?
Priority 1: Application crashes, no work around, data corrupted/lost
Priority 2: Application crashes, work around OR bug, data corrupted/lost, no work around
Priority 3: bug, no data corrupted/lost, no work around
Priority 4: bug, data corrupted/lost, work around
Priority 5: UI interaction, nuisance, no loss of data or work

This makes prioritizing bugs easy, but there are a lot of times a priority 5 issue, which is usually considered releasable, could be the downfall of an application. Meanwhile there could be a random crashing issue that occurs on one machine that gets fixed first because it is priority 1... not to mention, its so random it takes days to track down (there goes an entire sprint!)

Not only do these make little sense for prioritizing your sprint, they also offer no help when it comes to quantifying the impact of bugs on the teams velocity...

Introducing my new system of bugs:

Rules:
1. All bugs are stories
2. Like other stories, they are prioritized by the client and estimated by the team
3. If a bug appears as a direct result of a story completed in the sprint, it is added to the sprint and impacts velocity
4. Every sprint there is a small timebox to fixing/investigating bugs that the client hasn't included in the sprint (this doesn't affect velocity and the sprint should be planned accordingly)
5. Although the client prioritizes the backlog, the developers should feel confident about their codebase and may request bugs get fixed ahead of higher priority stories

What do you think?

The main idea is that bugs, like anything else, need to be user facing and should impact your velocity and sprint planning.

Like some other things, bugs happen :)

More about → where do the bugs go?

Sprint Planning

At the end of every sprint review, we have our sprint planning meeting... This is our most painful meeting. We've done a lot to mitigate the suffering and the pain has lessened in return. However, our process, like any, is not without flaws and some planning sessions just plain suck.

During sprint planning we review the user stories in our backlog. For our enterprise projects, Salim, our SCRUM master, keeps track of the stories and priorities and the rest of the developers usually know whats going on too. For the new product development our client proxy, Ilio, manages the backlog, which is always well thought out and organized.

Before the review, the developer's knowledge of the stories is anywhere from nothing to very familiar. The more unfamiliar we are with the stories, the more painful our meeting.

Makes sense, because unfamiliarity and uncertainty go very well together, and uncertainty, while unavoidable, makes for long conversations and design talk. Too many unknowns during one sprint review makes us desperate to end the meeting.

The meeting is suppose to go like this:
1. Salim reads a story card
2. On the count of 3 we hold up an estimation card (very easy, easy, medium, hard, very hard and unknown)
3. Salim writes down the estimation
4. repeat

This process repeats until we've estimated more than an iteration of work.

Seems pretty simple, right?

Except, it only happens that smoothly when:
1. The story and solutions are well known
2. Everyone is focused

Sometimes the process is more like this:
1. Salim reads the story card
2. Ilio is asked to explain what it means
3. Ilio explains the story
4. Someone disagrees with Ilio about some behavior on the card
5. Ilio explains the logic again (he's so calm its amazing) and if necessary goes to Bob, our user interaction guru
6. Salim asks if people are ready to estimate
7. Someone answers, "what story are we doing?"
8. The card is re-read
9. On the count of 3 we hold up an estimation card
10. There are only 2 estimations that match, the others range from easy to question
11. The highest estimation explains their reasoning
12. The lowest estimation explains theirs (unless they changed their minds)
13. Salim asks if we want to re-estimate
14. On the count of 3 we hold up an estimation card
15. Kris or Luke make a final decision if we don't agree
16. Salim writes down the estimation
17. repeat

That took a lot longer to read, no? Believe me it makes the meeting take a lot longer too!

Does this make you think we're disfunctional? I think we'd be disfuctional if it always went perfectly... That may sound odd, but its conversations like these that bring interesting design discussions, find issues we missed, discuss user interactions we don't like, etc. These are important conversations to have.

When planning gets filled with unknown stories, we'll have 15 minute meetings each day to discuss stories for the next sprint. This helps, but is difficult too, because its another meeting to fit in during non-war room hours and there is very little time as it is...

I think we all decided that we'd rather have one long day of meetings (which we're having anyway) and a slightly more painful sprint planning than think about sprint planning every day of the week.

At the end of it all, we just want to code :)

More about → Sprint Planning