Any particular points you hope I'll cover in this talk? Let me know! Also interested in what beliefs you feel hold teams back. Let's get some discussion going, it'll make the meetup that much better! See/talk to ya soon.

Slicing the stories reminds me of this. Recent conversation with a senior QA manager revealed that some stories were producing very large code modules; repeated refactoring only seemed to make the modules even bigger. It was getting out of hand. My suggestion was to decompose the stories and hence the code modules into smaller and simpler ones. A laborious redo but necessary. I thought it odd that the manager did not seem to want to pursue the conversation. Was it incorrect to suggest this?

Bob, when you talk about sprint zero and planning sprint, are you using them interchangeably or talking about two separate things?

Hi Manny,

I don't know the details, but it seems to me that once the code is written, might as well leave it alone. I'm a big fan of only refactoring code when there are new stories/defects that touch on that code.

That said, your basic point seems to be "smaller stories is better". In my experience, small story size is a hallmark of an successful Agile team. So I would say that any discussion towards that end is very appropriate!

Hi Bob,

I assume you are talking about an ongoing project? In that case, I agree with your assessment. For a new project, I think there has to be some time spent on creating/understanding the vision/domain of the project. That may be done by product management, but I think it is best when the team that will deliver the software is involved from the get go. I have a feeling you are mainly talking about avoiding the tendency towards building frameworks and big architecture. If so, I agree!!

So far we've talked about the following beliefs: "big stories are ok" and "BUFD is still needed". What other beliefs to you feel are holding folks back? What beliefs do you find you struggle with personally? One of the beliefs that I only let go of a year ago was that self organization was over rated (gasp!) But then I read a couple of books on the topic from outside our industry. Did anybody have a similar experience?

How about the challenges of "Product Management" versus "Product Owner" in a commercial s/w company? If you believe in the Pragmatic Marketing approach to Product Management, the Product Manager spends 30-40% of their time on the road talking to customers to ensure that they understand the ever-evolving requirements for the product. How then can they participate effectively in the daily prioritizations, meetings, and other activities that an Agile Product Owner must do?

Hi Dave. At my current client the Product Manager is not the Product Owner for the very reason you state. The Product Owner is very experienced, but doesn't have the same responsibilities as the Product Manager and can spend more time with the team. If you don't have someone who can fill that role, you might want to have someone you groom for that role. Ideally you want an agreement with the Product Manager to support the Product Owner getting very rapid answers to questions.

A problem I've seen in commercial s/w teams that are new to Agile -- How to ensure that issues discovered by QA during a sprint are addressed by Dev during a subsequent sprint. In practice, Dev doesn't deliver a testable build until near the end of the 1st sprint, which doesn't give QA enough time to test and identify issues in time to be prioritized for the 2nd sprint. Thus, QA is essentially a build behind throughout the entire release unless they extend each sprint or add bug-only sprints.

Bob,
Thanks for your comment. I agree that your approach could work -- but in a commercial s/w company, especially a startup (less than 200 people) where a rapid flexible development process is almost a necessity, there is simply not enough budget available for both a Product Owner and a Product Manager. Thus, the Product Owner role is often filled by a Dev Manager, who may have met only a few customers and thus may not understand ALL of the market requirements for the product.

Regarding QA, build smaller things that can be tested during the sprint, or focus on delivering story 1, then story 2, etc. Testable builds should be regularly available, not just at the end of the sprint.

How quickly can the Dev manager get an answer to a question from the Product Manager?

Hi Dave,

Phew! The whole product management/product manager/product owner subject is a topic in its own right! Certainly, our beliefs about product management in general need to change to adapt to Agile. At AccuRev, as in many cases (as Bob mentioned), there is both a product manager and multiple product owners. Personally, I think product management will be changing radically over the next several years as more forms of information exchange become common, such as UserVoice and other services

Dave,

Regarding your specific question, I think the role of product management changes in Agile. There is a realization that much of the work done prior to Agile was not actually used! Now the product management role can spend more time on the things that really matter, freeing up more time for interaction with the team. Over time, some of the PM function gets distributed into the team itself which further frees up PM to do more of whatever makes sense for their particular circumstances.

David, regarding the dev/QA offset by an iteration, I agree that is a common new-to-agile situation. I feel that is connected to a common initial belief that Agile is a lot like traditional development, but within a shorter cycle. It seems to be really hard to get to the point that stories are small (as Bob mentions) and that dev and QA are truly interleaved throughout the entire iteration. But that should always be the goal.

We've had some good discussion here. Let's see if we can hear from some more people. What beliefs do you find that people hold onto from traditional development that you feel are holding your organization back from fully realizing the benefits of Agile? How about "it is more efficient to do most testing at the end of the release" or what about "customers can't handle frequent releases?" What are you seeing?

One of the things that I've seen people hold onto is the notion of individual code ownership. I've seen people get pretty unsettled by the idea that someone else could "get in and start changing my code". Another challenge for some people/teams is the general idea of minimizing work in progress. Instead, teams often want to start on on several stories at one time rather than swarming on one or two and completing them in priority order.

Michael, do you find that in the case of code ownership, there is also a lack of knowledge/experience with unit tests?

Michael, in th case of swarming, what is your experience with teams you've been on as to how many folks could swarm a single story? How many folks were on the teams in total?

By the way, welcome to all of the folks joining the Nashua Scrum Club meetup! Don't forget to update your profile so we can all get to know each other a little better.

Hi Damon. Interesting question about lack of knowledge/experience with unit tests. I was going to add lack of unit tests/reliance on manual testing to my prior post but cut it off when I exceeded the character limit. However, I hadn't correlated it with the code ownership mentality.

In my experience with teams ranging from 4-12 members...I think the number of people that can swarm depends on the skills of the team members, the size and nature of the story, how the tasks are defined, the definition of done, and total team size. To maximize the ability to swarm I encourage granular tasks of 4 hours or less. I encourage team members to look first at the highest priority story when looking for a new task. If there's no task they can perform, then move down to the next story.

Another note on swarming...I strongly encourage people to become "generalizing specialists". People who, while they have are certain specialized skills, are also capable of doing as many other tasks as possible. Not only does this help improve the ability of the team to swarm, it also gives greater flexibility for the team to take on stories in the priority order defined by the Product Owner because there's less concern that the stories don't align with the team's abilities.

Great stuff on swarming Michael! I am also a fan of generalizing specialists. Goes well with collective code ownership and unit tests!

Whew! Lots of great discussion here. What other beliefs do people see? I'm thinking of beliefs that have been formed from long experience with traditional development that we bring with us into Agile and sometimes have a hard time noticing. Sometimes they carry over to Agile, sometimes not. Here's one I've noticed lately: the importance of accuracy of estimates. Still important? Not so much?

Another area of Agile / Scrum that I find challenging... defining the best size for a story. Too small and you can lose the connection between the story and the minimum functionality that the user needs. Too large and your sprint takes on much more of a "waterfall" approach. As an example, you typically need to be able to CRUD each object in your system. If each of these operations are separate stories, how do you ensure that all 4 get built at the right time? Is Kanban a good solution?

David, I tend to follow Mike Cohn's thinking on user stories. The best user stories are those that are separable and that have customer value individually. So, if there is something that doesn't work without another thing, probably just one story with multiple tasks. Wrt CRUD, it seems like there are a couple of situations. Often the objects already exist, you are just adding new capabilities. In that case, the CR&D parts are probably already there.

The opposite of the previous example: let's say you are doing an online survey. You could do CR&D for questions, but skip update and require the user to delete and start over if they made a mistake on a survey question. I've found the mantra of "every story stands alone" to be a terrific way to innovate in user story creation. It doesn't always work, but when it does and you find a new way to break up stories, it makes the following stories that much easier to break down.

As a fan of Kanban, I see the prereq for adopting Kanban as getting to the point that most user stories are no more than a week long (preferably days) and each provide user value on their own. Regarding "minimal functionality," I see that and story size as directly connected. That is, if the user can't get value out of a story by itself, then that is probably more of a task than a story. Conversely, any story that a user can get value out, no matter how little, is a valid story.