Agile - Developer friendly?

[samarthya saurabh]

The way Agile methodology is laid out it just expected that repeated incremental versions of (acceptable and ready to work on) solution would be churned out. A developer has a defined timeline with a number of tasks of a story(ies) with an estimated T-Shirt size (as per guidelines), this actually rules out any miscalculation in terms of problem at hand and closure of a user story cannot be achieved till the time all the tasks has been marked done.

A developer is burdened not only with the defined timeline but with quality + all basic unit testing + integration verification. If a user story is not properly documented or if number of tasks are not laid out comprehensively a developers time will never be accounted for. Making it more of a burden. A owner of story is also a very vague as a usually it is the product owner who knows what MUST be in the product and that defines the priority of tasks and stories and within a story a developer only knows which sequence of tasks makes more sense.

Your comments?

[Tim Ottinger]

Only a few comments:

1) It sounds like your stories are too large. We have a card or two on breaking them down.
2) Typically tasks aren't assigned to developers, but to teams. I wonder if you're in a half-state or I misunderstood.
3) I'm not sure what you mean when you say "a developers time will never be accounted for."

I think there is more to your context that I would have to understand, because your local version
of agile will naturally have local customizations. I suspect that there is less team focus and
collaboration with project owners than I would like to see. If I were coaching, I would investigate
that first. Since I'm not, I suggest you may need your scrum master or coach to look into it.

Sorry I'm not more helpful.
tim Ottinger

[Jeff Langr]

Tim brings up an important point: There are almost as many ways to approach agile as there are development shops. That statement should also reveal that there are plenty of sub-optimal ways to approach it. The key is to understand its underlying principles.

One such principle is that we seek rapid feedback: We want to be able to turn a story around in a day, perhaps two, maybe three at most. This requires much higher levels of true collaboration than people think.

Ideally, we (as development team) get the customer in the room; they describe a larger feature by telling us a story. Through discussion, some planning, and perhaps some design, we manage to break that feature into a number of smaller deliverables (each of which we can demonstrate to our customer to show them progress). We go off and build one feature at a time--as a whole team--over the course of the next day or two. During this time, we communicate with the customer to clarify the feature as needed; they in turn are working with QA folks to help pin down definitions for acceptance tests. These tests will not only let them and us know when the feature is done, but will also help describe the feature to us.

Once the feature passes all its tests, we look to move on. A key part of this is minimizing the amount of work in process (WIP), and instead focusing on as few features at a time as possible. Too many agile teams treat an iteration as waterfall/cube mode--they go off and each separately build their own pieces, then hope them all to magically integrate at iteration end. It is probably the most common, largest mistake an agile team can make.

Collaboration is not free--there is some overhead, and it takes some time to do initially. But the payoffs are tremendous in terms of bringing the team together and improving the product.

So: If you are not getting the detail you need in a story, you must push back, particularly if you know the person presenting the stories will not be around the next few days to answer questions, and particularly if you are not getting comprehensive, well-defined, understandable acceptance tests for each story. Unfortunately, too many places don't invest enough in making someone who can answer all your questions readily available. That makes little sense to me. In any case, if you can't get the answers you need, then agile--or any other process for that matter--is not going to be very successful.

As far as the quality thing and tests are concerned: Again, there is most certainly an up-front cost to learning how to work this way. For example, initially, it takes more time to understand how to do TDD, and do it effectively. But over time, it will keep your speed of development much higher than otherwise, as long as you use it as a springboard to keeping your design clean (i.e. through continual refactoring).

I've developed in plenty of teams as "just a" developer, and I've always seen the rate of development degrade over time because there was no continual attention to quality. Quality, as Deming said in one way or another, more than pays for itself over time.

Regards,
Jeff

[samarthya saurabh]

Tim Ottinger wrote:
1) It sounds like your stories are too large. We have a card or two on breaking them down.

The story usually is cut down to almost a feature requirement, but with a defines set of tasks, sometime related and sometimes un-related or by-products. How to decide if the story is too large? We just put down T-Shirt sizes to it and yes we do have Large, Medium and small as the sizes. What should be an optimum sprint size? Is it decided before hand or should it be based on the stories we tend to include or number of spill overs we have?

Tim Ottinger wrote:
2) Typically tasks aren't assigned to developers, but to teams. I wonder if you're in a half-state or I misunderstood.

Tasks are assigned to teams? I am not sure I understood it correctly. As in practice we as a team take up stories and tasks are assigned to individuals on voluntary basis, is it not the proper way?

Tim Ottinger wrote:
3) I'm not sure what you mean when you say "a developers time will never be accounted for."

Assuming there are a set of tasks and they are not completely related but, eventually when the feature goes live these tasks will have to interact. So considering an individual developing a task with relative independence has to interact at times with peers just to ensure the requirement or expectations are laid out for the members who will interact with his coded module. He has to interact with Test teams to make sure information is well conveyed. This is all because of lack of documentation (Zero documentation about design) and parallel development. A developers shoulders a responsibility of completing a task on time and in all probability might be reluctant to give the time required. If he does he cannot account it in any specific task, because these discussions takes time, sometimes too much. (I hope I am able to clarify)

Tim Ottinger wrote:
I suspect that there is less team focus and collaboration with project owners than I would like to see. If I were coaching, I would investigate
that first. Since I'm not, I suggest you may need your scrum master or coach to look into it.

What should be the focus? Design, development? I am afraid I am not able to understand. A little help?

Thanks.

[samarthya saurabh]

Jeff Langr wrote:
I've developed in plenty of teams as "just a" developer, and I've always seen the rate of development degrade over time because there was no continual attention to quality. Quality, as Deming said in one way or another, more than pays for itself over time.

This is my concern as well. We can have user stories that defines security, quality, performance requirements but these stories are usually hold less priority initially in a hurry to get to market. And we usually end up with pseudo-quality-security and worst performance at times.

How do we deal with it?

Thanks.

[Tim Ottinger]

samarthya saurabh wrote:

Tim Ottinger wrote:
1) It sounds like your stories are too large. We have a card or two on breaking them down.

The story usually is cut down to almost a feature requirement, but with a defines set of tasks, sometime related and sometimes un-related or by-products. How to decide if the story is too large? We just put down T-Shirt sizes to it and yes we do have Large, Medium and small as the sizes. What should be an optimum sprint size? Is it decided before hand or should it be based on the stories we tend to include or number of spill overs we have?

A story should be small enough to be completed within a few days of a sprint. It should be a slice of a Minimal Marketable Feature. One goal is to have almost half the sprint finished (shippable) by the midpoint of the sprint, and all stories completely shippable by the end. That's not 'coded' but coded, integrated, tested, etc since an agile team is everybody who works to make it happen (product owners, QA, developers, QC, sysadmins, tech writers, page stylists, DBAs, etc).

The ideal sprint size is "as much as you can deliver in every iteration for the rest of your life, sustainably." The best way to find that number is to measure your velocity and plan for no more than you did last week. We use "yesterday's weather" and "velocity tracking" to determine optimal size. If a story isn't completely ready to ship, we don't count it. So if we finished 8 points out of ten, the next sprint is an 8-point sprint. If we planned 8 and did 9, the next sprint is a nine-point sprint. Things tend to even out in a relatively short time.

This jump is to see 'velocity' in a new light. You're not measuring sprint speed, you are measuring capability. The whole team can only truly complete so much work per iteration, so you are trying to find out how much that is. Increasing the velocity isn't a matter of stepping on the gas harder, it's a matter of improving the efficiency of the team so that they are capable of more. It's a mental shift.

The analogy is optimizing by looking for better algorithms, instead of overclocking the cpu.


I hope I didn't take your question too far in this direction, it was just an observation.

[Tim Ottinger]

samarthya saurabh wrote:
Tasks are assigned to teams? I am not sure I understood it correctly. As in practice we as a team take up stories and tasks are assigned to individuals on voluntary basis, is it not the proper way?

If team members are each working alone on a task, then it's not the right way. The idea is to be "swarming" the tasks to get them done as well and quickly as possible. If each team member takes on a task and is solving it solo, then it's probably not what is intended. It's hard for a team to do if each is responsible for a different part of the work, because then stories tend to be completed in the last day of a sprint, and that's really hard to deal with.

Actually, I prefer if all the stories are _not_ assigned to individuals at the start of the sprint. I like the task cards to be placed on the wall, and picked up voluntarily. Developers should choose how to tackle each of them. I prefer them to be in priority order if there is a clear priority to them. This way, the team has the most flexibility to self-organize instead of racing one developer against another. It also leaves more room for non-programming team members to be involved.

[Ernest Friedman-Hill]

samarthya saurabh wrote:We can have user stories that defines security, quality, performance requirements but these stories are usually hold less priority initially in a hurry to get to market.

These things are not stories: they're cross-cutting concerns that are part of every story.

[Tim Ottinger]

samarthya saurabh wrote:
Assuming there are a set of tasks and they are not completely related but, eventually when the feature goes live these tasks will have to interact. So considering an individual developing a task with relative independence has to interact at times with peers just to ensure the requirement or expectations are laid out for the members who will interact with his coded module. He has to interact with Test teams to make sure information is well conveyed. This is all because of lack of documentation (Zero documentation about design) and parallel development. A developers shoulders a responsibility of completing a task on time and in all probability might be reluctant to give the time required. If he does he cannot account it in any specific task, because these discussions takes time, sometimes too much. (I hope I am able to clarify)

So you mean that the developers' time is not accounted for in the estimates? That's a different problem than I thought.

1) Agile does not require us to have zero documentation about design, it only reminds us that it is not the best way to share information.
Typically the whole team will talk through the story before estimating, so there is a meeting about a feature where everyone gets
on the same page. Then if something changes, any team member in the bullpen can stand up and discuss the change.
We might still have whiteboard sketches, mockups, and the like. It's there if it helps everyone in the room understand how
the change works. I remember one successful agile team who had a meter-wide mockup of the screen in the room with
sticky notes on it. It helped them stay focused on the work.

2) Does the whole team make the estimates? It almost sounds as if you are bound to someone else's time expectations.
If you are underestimating as a team, try rounding up. Development should not be leisurely, but it should not
impoverish developers or writers or QA team members. At the end of the iteration, everything has to be done
and shippable (whether shipped or not) so the process has to work for everyone.

3) Do you track velocity? If you measure how much is totally shippable in an iteration, and plan by "yesterday's
weather", underestimation smooths out quickly. When the iteration is a near thing, the team will have a tendency
to start rounding their estimates up a bit. They hit their stride in a few iterations.

4) Is there some tracking and reward system that punishes (or fails to reward) the individual if they help others?
Anything that pushes against teamwork is non-agile, since agile values teamwork (interactions) so highly.

Some of these things are mentioned in our teamwork cards. In the card titled "is your team circling the drain?"
we mention:
* Individual work assignments
* Piles of unfinished work
* Work assignments given under the table
* Empty ceremonies
* Neglect of quality practices
* Guarded speech

Of those, your initial question had me questioning the first two.

Regardless, a few questions to bring up in your next retrospective:
> Do you have enough teamwork to thrive (not just survive) without documentation?
> Are you swarming tasks so that each is finished as early in the iteration as possible?
> Is the estimation working for everyone, or does it pit one against another?

[samarthya saurabh]

Tim Ottinger wrote:
Agile does not require us to have zero documentation about design, it only reminds us that it is not the best way to share information.

Development should not be leisurely, but it should not impoverish developers or writers or QA team members.

Indeed, I agree to it completely.

Tim Ottinger wrote:
Do you track velocity? If you measure how much is totally shippable in an iteration, and plan by "yesterday's
weather", underestimation smooths out quickly. When the iteration is a near thing, the team will have a tendency
to start rounding their estimates up a bit. They hit their stride in a few iterations.

Yes we do.

Tim Ottinger wrote:
Is there some tracking and reward system that punishes (or fails to reward) the individual if they help others?
Anything that pushes against teamwork is non-agile, since agile values teamwork (interactions) so highly.

Probably it is not just about the ONE - team working one project but when knowledge is the key and a resource expertise might prove valuable to some other projects, his time needs to be borrowed and that is when the resource is reluctant may be because he is thinking of the task and the sprint. This is not always the case but yes I have certainly seen that.


Thanks any ways! the discussion indeed was to my liking and I did get few pointers which I can certainly use moving forward.

[Tim Ottinger]

samarthya saurabh wrote:
Probably it is not just about the ONE - team working one project but when knowledge is the key and a resource expertise might prove valuable to some other projects, his time needs to be borrowed and that is when the resource is reluctant may be because he is thinking of the task and the sprint. This is not always the case but yes I have certainly seen that.

Oh, well then no problem after all. Since you go by velocity and yesterday's weather, then your people should help anyone who asks. We used to have a rule, "If someone asks for help you cannot say no." Since developers are always being pulled out to help other people, it is "normal" and the velocity adjusts for it. Provided you don't have individual assignments you're responsible for (a smell), velocity absorbs all the normal jitter in the system. It's a pretty simple, smart system.