17

Our small software team is developing a web application. All devs are very dedicated and working hard to meet the deadline. Nonetheless, when the release is deployed, it is not really perfect. All core functionality is working (tests pass etc), but some fine-tuning is missing: eg. some buttons in the UI are not aligned, some text using templates is not working well in some languages etc.

These details are not blockers and will be fixed in the next sprint & release (the functionality on time is key).

So the application gets deployed, but it's not really looking great and that's the feedback you get from the non-tech people in the company. "Job half-done". How to still celebrate the hard work and dedication which went into the release, if the final product isn't really convincing the non-tech people (even the devs agree that more work is needed, but have concentrated on the functionality)?

In general, when using iterative methodology (small changes, release often), there is no big-bang after which it really makes sense to celebrate. How to still celebrate releases? How to build up pride for the work done?

5
  • 2
    Yes, but at that point only one Dev is still doing the fine tuning. The others are already working on the next features. So the big effect is lost.
    – Philipp
    Jun 3 '15 at 11:02
  • Every minute you spend celebrating something that's not finished yet is a minute that you're taking away from finishing the project. You are asking for something premature. Not cool. As Yogi Berra used to say: " it' ain't over until it's over" Have your celebration when you know it's over. You don't like delayed celebrations? That's fine. Learn to like them anyway. Jun 3 '15 at 11:26
  • @Philipp Even so, when that point comes up they presumably can be invited to the resulting celebration, no?
    – KRyan
    Jun 3 '15 at 15:58
  • 2
    @VietnhiPhuvan: “Have your celebration when you know it's over.” That’s the beauty of agile! It’s never over! It’s just an eternal series of fortnightly sprints! Jun 3 '15 at 16:21
  • 1
    @PaulD.Waite - That's not unique to Agile. 20 years ago we all heard the phrase, "Software is never done. It's only abandoned." Jun 3 '15 at 17:24
25

In general, when using iterative methodology (small changes, release often), there is no big-bang after which it really makes sense to celebrate. How to still celebrate releases? How to build up pride for the work done?

When you dribble out releases, you are correct that there is no definitive point ("big bang") where it makes sense to celebrate.

So look outside your release schedule for meaningful events connected to your work, and celebrate those occasions.

First Customer or First Download are significant events at some shops. 1,000,000th Download might work at some companies. Sales Goal Reached might work elsewhere.

Some shops celebrate each iteration in a smaller, non-big-bang, way. A pizza lunch, bagels for breakfast, etc.

It's not always necessary to have a big celebration. Iterative approaches certainly blur the line between "in progress" and "complete". Sometimes you cannot achieve a "big effect" and must learn to enjoy many "little effects" instead. A terrific writer I know used to refer to "inch-pebbles" versus "milestones".

8

To prevent full-focus on functionality, have someone assigned to focus on the UI when about 80% of the functionality is finished. If that person can put all his effort into the UI, the non-technical people will be less likely to criticize your work as "job half-done" because you had someone take care of the UI.

As for the celebration, why not do that after each sprint? I always used to be a bit relieved when we finished a sprint, and if everybody is happy with the work delivered in that sprint it's worth celebrating. You could do this by kicking back with a couple of beers, or some cake. Or whatever rows your boat :) I would recommend to keep it simple though.

1
  • Yep, a box of doughnuts or something at the end of a sprint usually suffices. If people want to do something a bit more celebratory, have a meal/whatever at the point when you move on from that application to something else, or kick off a fresh phase or something.
    – Hazel
    Jun 3 '15 at 10:31
4

If you put enough releases out that are not immediately welcomed with open arms by the customers, they will start to dread updates and have a low opinion of the team's ability to deliver. This will also start to impact team morale.

It's good that you recognize that the team is doing their best and external circumstances (e.g. unreaslistic deadlines) are the root cause of poor initial feedback. It's important to recognize that you have a strategic problem (how to deliver a truly successful release on time) and a tactical problem (how to keep the hard working team motivated in the face of external pressures).

Some short term rewards that might help are having a team dinner, giving public thanks for their efforts, getting the customers to recognize how quickly improvements are made based on their feedback, etc.

The strategic problem is where you should focus your efforts though. You want to get to a place where you do not need to be celebrating partially achieved goals. Two possible ways you might approach this are getting more realistic timelines for the required scope or reducing scope for given timelines so it can be delivered successfully.

0

I read through some of the answers and they touch upon my thoughts but don't give the definition and clarity, so I'm going to give my answer.

We did the area's first agile release and it lasted about two years. It was well received and has caused a butterfly effect into other parts of the area. That being said, we did something called: Sprint Retrospectives

I posted an official MSDN link from Microsoft, but, as with any agile team, the rules are meant to be flexible. We used the retrospectives as a simple way to determine what we should start doing, things that didn't go well, and things that we should celebrate.

Usually the Project Manager would buy some food and we would eat and discuss. We never went to a restaurant and I think that was key because it helped us stay focused on the Sprint and achieve something from the retrospective, while allowing us to celebrate what we all liked from the sprint.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .