In terms of our company's evolution as we adapt Agile, we've moved toward having the work we need to do expressed as "user stories." But (in addition to learning how to write them) we've had a problem figuring out how long it takes to do a story (its "size") and then figuring out how many "stories" we can do in a sprint. So the question is - what size is the right size? Several people have been trying to answer that question within my company, and they've come up with this answer (which has been distributed around the team). I've edited it, but I didn't write it.
_____________________________________________________________
Sizeable should be Small.
And the Small is quite important. You want a number of stories in each sprint to :
· Increase the chance of getting as much work “done-done” as possible.
· The more stories you have, the smaller they are, which means more detailed acceptance criteria which means more accurate estimates and manageability.
Many of the teams working in my company have a problem breaking things down. Part of this is getting the user stories right so that it is clear what the Product Owner wants to achieve. The other part is having skill in being able to break things into smaller pieces. Some techniques (for web based work) are:
1. Separate user stories per site. Make the changes on one site and then have separate stories for each.
2. Progressive enhancement. Make a very simple feature in the first story and then add extra sub features in subsequent stories. (Stories are meant to be independent but in the case of an enhancement that builds on another story, clearly you have to be less rigid). For example, you may choose to first implement a new workflow in one story and then make adding validation as another story.
3. CRUD (Create Read Update Delete) may not need to be done at the same time. Consider releasing an input form first and then later adding the edit or delete functionality.
4. Data partitions – Some complex projects require the migration or cleaning of large amounts of existing data. One approach is to focus on the most valuable data partition first and then add additional stories to deal with less important cases and edge cases. This avoids projects stalling while the team gets hung up dealing with non valuable edge cases. For example, my company had a partner ask us to de-dupe all of our data in our Billing and Contracts DB. We knew that a project had stalled the previous year when trying to de-dupe the data so we took the approach of just focusing on the Billing Contacts. This was the highest value group to the PO and was easy for us to de-dupe.
5. Evolution. Sometimes it’s better to start from scratch. But most of the time at my company, we are enhancing an existing piece of functionality. When creating new workflows, there is an option to “evolve” over a number of sprints - basically, take an existing workflow and tackle small stories one at a time.
6. Iterate. If your acceptance criteria sound like they will require a lot of work, sometimes all you need to do is take the criteria and turn them into child stories. When you do this, you then realize how big a single acceptance criterion is and you can add more criteria to it to help with the estimates and everyone’s understanding of the project. Sometimes you might find that you need to break these stories down even further. You can use record cards on a table in the backlog workshop and arrange them into a hierarchy if it helps. Visualizing the problem in this way can really help.
7. Draw pictures. Draw pictures of how new pages/controls/reports might looks. You can then use a red marker pen to outline sub elements and ask yourselves “can this bit of the pages be split of into a separate user story?”
Slicing isn’t easy. It takes time to rotate the problem in your mind and come up with different solutions. Sometimes, setting aside some time in a team’s backlog session to explicitly brainstorm and discuss different options helps; sometimes taking it away and thinking about it on your own is the way to go. Some good rules of thumb when slicing are:
1. Have we sliced it small enough so that we can fit more than one story in a sprint (3+ is ideal)?
2. Can this story be released on its own and give value for the Product Owner?
Generally brilliant user story presentation (not really about slicing):
http://www.mountaingoatsoftware.com/system/presentation/file/97/Cohn_SDWest2009_EUS.pdf
In depth article on splitting:
http://radio.javaranch.com/lasse/2008/06/13/1213375107328.html
Wednesday, 15 July 2009
Wednesday, 1 July 2009
Agile pretty, agile ugly
In this last week I've seen some stunning examples of Agile working really well, just like I'd expect it to - but also really badly.
First, the good. We've got developers writing automation, which I was reviewing with them in conjunction with an automation QA specialist (who's been using our automation framework for 20 hours a week versus my 5 hours a month) who was providing direct information about our automation standards (i.e. "add in 'verify negative' tests here"). We saw where a link was hard-coded where it should have been dynamically generated - and the developer who's been coding the link was able to work on changing it immediately from our feedback. And the automation was also changed to remove a kludge that had been put in to make it work with the hardcoded link (which didn't work on our uniquely-addressed test servers). Five minutes of cross-team conversation leading to a host of changes and fixes with low overhead - totally cool.
Now the bad. It's my belief that the fetish for documenting things dynamically and on index cards really shortchanges the value of really solid research about the work we are supposed to be doing. Our project for this sprint has specified we make a certain change on two pages, which can be expressed either as .asp or .html pages, so that one of them is the canonical version - but the problem is that we actually have four different ways of accessing these pages (including through redirects from old versions of the pages and via links sent in emails), so there are actually a host of different versions of these essentially identical pages. But the team only had a narrow set of them identified/known to exist when we agreed to do this work, and now there are time considerations for not doing it for the other pages - which dilutes the effectiveness of the project. When you've got people working on areas they don't know very well this is bound to happen - but I think it's an inherent problem of Agile of underdefining what we need to do in order to acheive speed. Speed and mediocrity - as a QA person, it's not really a happy place to be in, releasing something that meets what was asked for but fails to achieve the spirit of it.
First, the good. We've got developers writing automation, which I was reviewing with them in conjunction with an automation QA specialist (who's been using our automation framework for 20 hours a week versus my 5 hours a month) who was providing direct information about our automation standards (i.e. "add in 'verify negative' tests here"). We saw where a link was hard-coded where it should have been dynamically generated - and the developer who's been coding the link was able to work on changing it immediately from our feedback. And the automation was also changed to remove a kludge that had been put in to make it work with the hardcoded link (which didn't work on our uniquely-addressed test servers). Five minutes of cross-team conversation leading to a host of changes and fixes with low overhead - totally cool.
Now the bad. It's my belief that the fetish for documenting things dynamically and on index cards really shortchanges the value of really solid research about the work we are supposed to be doing. Our project for this sprint has specified we make a certain change on two pages, which can be expressed either as .asp or .html pages, so that one of them is the canonical version - but the problem is that we actually have four different ways of accessing these pages (including through redirects from old versions of the pages and via links sent in emails), so there are actually a host of different versions of these essentially identical pages. But the team only had a narrow set of them identified/known to exist when we agreed to do this work, and now there are time considerations for not doing it for the other pages - which dilutes the effectiveness of the project. When you've got people working on areas they don't know very well this is bound to happen - but I think it's an inherent problem of Agile of underdefining what we need to do in order to acheive speed. Speed and mediocrity - as a QA person, it's not really a happy place to be in, releasing something that meets what was asked for but fails to achieve the spirit of it.
Wednesday, 24 June 2009
Amazing differences between Agile teams
I've been moved to a new team as a part of a small reshuffle. I'm very happy about this - it's like being adopted by a family of people that all get along.
Note from today's planning session: it is SO MUCH NICER to come to a planning session when you've already worked out what the tasks are (mostly) for the stories you're estimating - it really reduces the effort in getting the time estimates done because you understand the work so much better.
Note from today's planning session: it is SO MUCH NICER to come to a planning session when you've already worked out what the tasks are (mostly) for the stories you're estimating - it really reduces the effort in getting the time estimates done because you understand the work so much better.
Friday, 22 May 2009
Four months into Agile: a retrospective
Our scrum master has quit, my best friend has been laid off (because the company doesn't need product analysts anymore), and I'm on the team that's considered the worst in the company.
My morale is low.
My morale is low.
Friday, 13 March 2009
Improving your chances of successfully rolling out Agile by being better prepared at the start
Over the course of the last month plus, I've been very frustrated by how things have gone within my new team - that has been newly made Agile - in a company that's just gone Agile (as of January 6th, a rolling rollout across seven or so teams). Working through this, I see several books in the making - because there is so much information that people need about how to really make this work and I'm not sure if there's enough literature out there to cover it. Yeah, sure, you can hire a coach to help your company make the transition, but it's really expensive, and how do you know you're going to get the right person for the job?
So ... our training, across the department, pretty much consisted of some two days that made us "Scrum Masters." Now, this is about the most useless training I've ever had for the money, and you aren't actually properly trained to be a "scrum master" (as in "the person who runs interference for a scrum team") and you're sure as hell not a master of Scrum practice just because you've spent two days learning about how to properly scope the amount of work you can do in a sprint. Worse yet, people come out of it thinking they know how to do Agile when in fact they only know how to do the tiniest bit of Agile. Scrum Master training is basically aimed at developers. It ignores the needs for requirements gathering, documentation, testing, and releasing a product - and if that's where you are involved in the software lifecycle, you will come out of the training thinking there is no role for you in the new world. But this is Not So.
So, if you're looking to switch your company to Agile, what can you do to most ensure success? I expect there is a lot more to say about this that I will in just this post, but what I would like to encourage people to do is learn how to build a product backlog. The moment when the team comes together for the first sprint estimation meeting is a month or two too late to be starting this work. The product owners need to learn how to start expressing what they need in a way that can help a team make good estimates, rather than just producing a list of tasks that all require further investigation, and someone needs to make sure the results of this research are somewhere that the team can access, so that (for example) the QA folks can work on developing extensive acceptance criteria during their down time in the sprint rather than waiting until the actual point where the work for a sprint is being chosen to decide what the verification points are going to be. (These meetings move fast, and its difficult to spend the time you need to develop these tests fully when it's holding up moving on to the next item for estimation.)
I think this is where we've critically failed. We didn't have enough in the backlog to start with, which meant we didn't have enough work to prioritize the first day (and we ran out of time rathe than running out of work to do), we didn't spend time during the sprint working to further flesh out our backlog, and ultimately our team probably operated at 60% of what our capacity should have been for the sprint. We didn't know where to go to get work and we didn't have the work prioritized so we could just "grab the next card." Result: a very frustrating first sprint, and, I'm sorry to say, a second sprint that is about to start without a sufficient definition of the work we are going to be doing.
Next up I expect I'll be talking about how to create user stories.
So ... our training, across the department, pretty much consisted of some two days that made us "Scrum Masters." Now, this is about the most useless training I've ever had for the money, and you aren't actually properly trained to be a "scrum master" (as in "the person who runs interference for a scrum team") and you're sure as hell not a master of Scrum practice just because you've spent two days learning about how to properly scope the amount of work you can do in a sprint. Worse yet, people come out of it thinking they know how to do Agile when in fact they only know how to do the tiniest bit of Agile. Scrum Master training is basically aimed at developers. It ignores the needs for requirements gathering, documentation, testing, and releasing a product - and if that's where you are involved in the software lifecycle, you will come out of the training thinking there is no role for you in the new world. But this is Not So.
So, if you're looking to switch your company to Agile, what can you do to most ensure success? I expect there is a lot more to say about this that I will in just this post, but what I would like to encourage people to do is learn how to build a product backlog. The moment when the team comes together for the first sprint estimation meeting is a month or two too late to be starting this work. The product owners need to learn how to start expressing what they need in a way that can help a team make good estimates, rather than just producing a list of tasks that all require further investigation, and someone needs to make sure the results of this research are somewhere that the team can access, so that (for example) the QA folks can work on developing extensive acceptance criteria during their down time in the sprint rather than waiting until the actual point where the work for a sprint is being chosen to decide what the verification points are going to be. (These meetings move fast, and its difficult to spend the time you need to develop these tests fully when it's holding up moving on to the next item for estimation.)
I think this is where we've critically failed. We didn't have enough in the backlog to start with, which meant we didn't have enough work to prioritize the first day (and we ran out of time rathe than running out of work to do), we didn't spend time during the sprint working to further flesh out our backlog, and ultimately our team probably operated at 60% of what our capacity should have been for the sprint. We didn't know where to go to get work and we didn't have the work prioritized so we could just "grab the next card." Result: a very frustrating first sprint, and, I'm sorry to say, a second sprint that is about to start without a sufficient definition of the work we are going to be doing.
Next up I expect I'll be talking about how to create user stories.
Thursday, 5 March 2009
The Eternal Questions of the Spotless Scrum
Much as people question, "Why does bread fall butter side down?" and "Why is something always in the last place you look for it?" I find that Agile has its own eternal questions. The one that is the most problematic is, "Why is it that it's so hard to get business owners to commit enough time to get the work done?"
Thinking about it, there are two things that probably ought to change. The first is in properly training the business owners about the change in their responsibilities. This should be part of the agile ramp-up in an organization (and was a step we skipped), and should include information like how to work the product backlog and how to develop user stories.
The second thing is more difficult to manage and has to do with freeing up their time. It's one thing for the development organization to say they're going Agile; it's another thing for a business owner, who, says, has responsibility for managing a team of (let's imagine) customer service agents, can suddenly make all of his other work go away and sit around "being available" for the team that needs his input rather than being there for the team he actually needs to manage. This is a much more difficult thing to work around, though colocation helps (not that I think a Dev team really wants to sit in a call center), but also anticipating this by reducing other duties a business owner might have is a possibility.
How has your company handled this?
Similarly, I'm curious about initial velocity calculation, for when you're trying to figure out hw much work you can get done in your first sprint. We had no estimations of the number of actual hours our team could work during a week, so we just made it up based on what we felt comfortable saying yes to - and wound up being 25% under our actual capacity based on when we've run out of work. Ideas on how to manage this?
Thinking about it, there are two things that probably ought to change. The first is in properly training the business owners about the change in their responsibilities. This should be part of the agile ramp-up in an organization (and was a step we skipped), and should include information like how to work the product backlog and how to develop user stories.
The second thing is more difficult to manage and has to do with freeing up their time. It's one thing for the development organization to say they're going Agile; it's another thing for a business owner, who, says, has responsibility for managing a team of (let's imagine) customer service agents, can suddenly make all of his other work go away and sit around "being available" for the team that needs his input rather than being there for the team he actually needs to manage. This is a much more difficult thing to work around, though colocation helps (not that I think a Dev team really wants to sit in a call center), but also anticipating this by reducing other duties a business owner might have is a possibility.
How has your company handled this?
Similarly, I'm curious about initial velocity calculation, for when you're trying to figure out hw much work you can get done in your first sprint. We had no estimations of the number of actual hours our team could work during a week, so we just made it up based on what we felt comfortable saying yes to - and wound up being 25% under our actual capacity based on when we've run out of work. Ideas on how to manage this?
Wednesday, 25 February 2009
It's all gone very Lord of the Flies
We're at the end of our secnod month of the Agile conversion at work and things are ... rough. Many of the senior non-development people that work here are talking about leaving in private discussions. Excluding coding, the work to be done seems excessively trivial. Too many people feel like the skills and specialisms they've honed are no longer getting used, and instead they're frittering away their time on projects that are small in scope mentally as well as physically (if that makes sense). The conclusion is that if the economy was better we'd have already seen people leaving, but they're hanging on - though the resumes are already going out. Even the person who sits next to me and is consistently chipper and "let's look on the bright side of things" is saying that her work life on a daily basis is rotten.
Meanwhile, the atmosphere of "everyone can do any task" has led to an environment I liken to Lord of the Flies - the savages have painted their cheeks and declared themselves to be Product Managers (or UI developers, or Business Analysts) because they went to training where they were Told They Could and no one is stepping in to stop them. So in Sprint Planning meetings I have to listen to people spend two hours arguing over what "done" is because they are all now Agile experts, and in another team all seven people are having to work out what the requirements are for a project because They Are Empowered Now and no one bothered to do the research beforehand (not even enough to do an estimate) because to plan what you're doing before a sprint start is Crypto-Waterfall Apologism, don't you know. Too many people are running out of work to do long before their sprints are over (again with the lack of planning), but we're stuck with overly-long sprints created by executive fiat and fixed resources "because in training they said sharing people is a risk."
I am really hoping that a lot of these things will get ironed out in the next month but being stuck in the middle of things makes it very difficult to have a good attitude about it. I do feel like for a lot of senior specialists (like myself) Agile is not really offering the kind of career growth and challenges that I want, and I fear that between the abyssmal morale and the change in what's required of us, we will be having a substantial amount of staff turnover.
Lesson here: two days of training is not enough (everyone got the same training, from the developers to the scrum masters to the UI developers and QA) and a lot more planning should have been done before we started this process so that we could have hit the ground running and got a lot more out of our first sprints, rather than burning so many people out at the very beginning. I would have especially looked at something really intensive for the scrummasters so they knew how to get maximum use out of their teams at the very start, and they could have percolated expectations (and work) back down to their groups so that they knew what to do at the start rather than flailing around like we have been.
Meanwhile, the atmosphere of "everyone can do any task" has led to an environment I liken to Lord of the Flies - the savages have painted their cheeks and declared themselves to be Product Managers (or UI developers, or Business Analysts) because they went to training where they were Told They Could and no one is stepping in to stop them. So in Sprint Planning meetings I have to listen to people spend two hours arguing over what "done" is because they are all now Agile experts, and in another team all seven people are having to work out what the requirements are for a project because They Are Empowered Now and no one bothered to do the research beforehand (not even enough to do an estimate) because to plan what you're doing before a sprint start is Crypto-Waterfall Apologism, don't you know. Too many people are running out of work to do long before their sprints are over (again with the lack of planning), but we're stuck with overly-long sprints created by executive fiat and fixed resources "because in training they said sharing people is a risk."
I am really hoping that a lot of these things will get ironed out in the next month but being stuck in the middle of things makes it very difficult to have a good attitude about it. I do feel like for a lot of senior specialists (like myself) Agile is not really offering the kind of career growth and challenges that I want, and I fear that between the abyssmal morale and the change in what's required of us, we will be having a substantial amount of staff turnover.
Lesson here: two days of training is not enough (everyone got the same training, from the developers to the scrum masters to the UI developers and QA) and a lot more planning should have been done before we started this process so that we could have hit the ground running and got a lot more out of our first sprints, rather than burning so many people out at the very beginning. I would have especially looked at something really intensive for the scrummasters so they knew how to get maximum use out of their teams at the very start, and they could have percolated expectations (and work) back down to their groups so that they knew what to do at the start rather than flailing around like we have been.
Subscribe to:
Posts (Atom)
