Sunday, December 6, 2009
Here’s what I mean by a personal scrum board. I have a whiteboard in my office divided into columns: backlog, staged, in process, ready for review, done. I keep track of all of my work on sticky pads very much in the same way as story cards. I also give each task a priority based on customer value. Work moves from column to column, eventually into the done column. I purposely keep work in process to one or two items and when a higher priority items pops up, it gets moved into the top of the staging column.
All of this seems like simply making a list and executing the list. That’s true, but the real power of the board is the agile processes that I can pull into my personal work. The board gives me plenty of visibility to those who work with me. I also have a morning daily planning session (by myself) before I begin work. I make sure that if anything that doesn’t flow through the board in a couple of days is evaluated to see why is it stopping up the flow. I also keep an impediment list that everyone coming into my office sees – my manager is responsible for helping with the impediment list.
If you’d like to try a personal kanban board, there’s information on the net for determining how kanban works. I’d encourage you to investigate and try it. Corey Ladis has a lot of information on: http://leansoftwareengineering.com/
Story points are meant to categorize stories by effort and size. Once you’ve initially categorized your work via story points, you pull in a few stories into your first sprint and then sum up the number of points you think you can do. Once the sprint is complete, you see how many story points you’ve actually completed and that becomes your initial velocity. If you are consistent in estimating story points, you can begin to figure out how many story points you can take in based on velocity.I think the reason story points are so fishy to a number of people is that they’re anchored in velocity, which is something that a new, forming team, doesn’t have yet. Once you’ve completed a few sprints, you’ll have a velocity and a set of canonical stories for each group of story points that you can then hang your hat on.
Sunday, November 15, 2009
After thinking about it quite a bit, agile collaboration is part of my upbringing, being a musician. I'm not just a musician, but the lowest form of musician - a bass player. I play tuba and bass guitar and it's pretty unusual for a bass player to take the lead - particularly a tuba player. The job of a good bass player is to support the rest of the band by providing a heartbeat and foundation. When playing bass guitar, I've always felt myself more of a percussion player with notes than another type of guitar player. It's better to play one note or rep over and over correctly and on beat than a Vic Wooten style riff that doesn't work.
Musicians, by nature, have to collaborate. They have to support eachother or have a collective train wreck. While there is some ability to grab glory, the point of the music is the product itself, not the spotlight of a solo.
Next time you're thinking of how agile is different, think about musicianship and the mutual support of musicians. It'll change the way you think of the project.
Friday, July 17, 2009
Here's a trick. After a few sprints, create a spreadsheet of story references, their points, and the sprint in which they were played. Sort the spreadsheet by point, sprint, then reference. Next time you go to a story pointing session hand out the list to the entire team and use this as a reference when someone trys to split hairs with a story. The point of the matter is to keep pointing consistent among the stories, not highly precise.
As time goes on, the team can strip stories from the spreadsheet that no longer seem like good representatives of that size.
This technique works great!
Tuesday, July 14, 2009
Are user stories better than other types of requirements specification?
User stories are narrative texts that focus on the value a user gains from the system. The basic thing about a real user story is that it's a metaphor for the work being done, not a highly documented requirement. The intent is to enhance collaboration about the topic of the user story - in other words in agile development (good agile at least), the documentation is secondary to the collaboration.
We value people over process, remember? Any technique may be flawed, but it’s the individual and team that can make it work or fail . If someone is used to iterative approach I believe they can make the other use cases and user stories work. If someone is steeped in big requirements up front (BRUF) then they will bring that style to user stories and end up with traditional requirements that are termed stories. At the end of the day it’s the individual that’ll make a technique fail or succeed.
As agile coaches and authors, we stress people and the importance of people and the team, but all too often focus on techniques, not the intent of the techniques or the underlying values of the agile manifesto.
So are user stories the best way to document requirements? Yes, if and only if you can foster collaboration. If your writing user stories and not seeing collaboration, the user stories are not helping and you might as well write traditional requirements (or better yet start to emphasize collaboration).
Tuesday, June 30, 2009
My biggest question is not that it's a tough market, have people lost the courage to stand up to non-agile or ill-conceived management decisions? With the corporate stand being one of "do it or we'll find someone who will" doesn't this make our jobs that much harder? I posed this question to Ms. Rothman and the answer is obviously yes. It was interesting that her answer also included the idea that people are staying at the wrong job longer, rather than chance moving to a new opportunity for which they may be better suited.
Think about that for a moment - not only is the economy putting pressure on people to perform in a manner that may be beyond reason, it's keeping the wrong people in the wrong position. When we have a turnaround in the economy the chickens will come home to roost.
This is a great time for a forward thinking company to bring on the best people and innovate - not just survive. With so many corporations cutting corners and developing products or supporting products in survival mode, those that take advantage now and look toward growth will be richly rewarded when the economy turns around (and it will) and competition is just starting to innovate.
For individuals, now is the time to really dig into what you're doing. If you are in QA, dig into the code and learn to write fixtures, if you're a BA, learn to read the code, if you're a scrum master, you need to wear an architect hat. Now is not the time to simply be a manager - learn something new on the job to enrich your resume.
Sunday, June 28, 2009
Thursday, May 14, 2009
Friday, April 17, 2009
Wednesday, April 15, 2009
I've seen, in many cases, where everything should be laid out in detail before a certain amount of work begins. These decisions are made based on perfunctory designs or shallow analysis - not good. When should these decisions be made? Later - when needed.
Thursday, March 5, 2009
Story points are a measure of relativeness and cannot be used right out of the box. They’re typically used in terms of duration and they have to be calibrated over time. The difficulty with story points is that they are put together in terms of numbers and people like to use numbers for statistics.
For example, does it take you more time or less time to drive from Atlanta to Charlotte than to drive from Cleveland OH to Akron, OH - certainly less. Does it take you more time or less time to drive from Seattle to Miami, probably more since it’s a longer distance. Story points are all about putting a stake in the sand and comparing other work to that reference point.
So let’s take example. I’m going to use the scale 1, 2, 3, 5, 8, 13, 20, 40, 80 as my story points for driving – roughly based on the Fibonacci sequence. We’ll call driving from Raleigh to Charlotte a 5. I’ve done that a number of times and know about how long it takes. I picked 5 as a starting point just to get a number in the middle of the pack. The relationship of the numbers is a factor of 2. What this means is that when compared to a 5, a 3 is ½ the duration, an 8 is twice the duration. 13 is twice the duration of 8 and so forth.
So as you estimate, compare everything you can to the base story – in our case driving from Raleigh to Charlotte. When an argument arises about a story being, say, an 8 or a 13, compare the story being estimated to others that have already been completed. Is the story in hand similar to the 13 we did last week or closer to the 8 we did? In the end remember that precision isn’t the goal, consistency is. A story that’s underestimated in the long run will balance another story that was over estimated. If you’re using story points to determine what can be accomplished in two week iterations, chances are you will only make a week’s worth of error.
Now we’ll story point driving from from Emporia KS to Guymon OK, Trinidad CO to Pueblo CO, Rome GA to Arab MS, Cleveland MS to Cleveland OH? Let’s look at google maps and order them by distance and side roads. I’ll just list the starting points: Trinidad, Rome, Raleigh, Emporia, Cleveland. Now we can start to story point. Is the Rome trip ½ the time as the Raleigh trip? Probably so we’ll point it as a 3. Is Trinidad ½ the time as Rome? It’s close but more likely not ½ the time so we’ll point is as 3. Is Emporia twice as long as Raleigh? I think so and that makes the time a point of 8. How about Cleveland? Twice as long as Emporia? Certainly. Even more? Yes, so a 13 doesn’t cut it. Is it as long as a 40 (in other words more than 4 times as long as Emporia)? Perhaps, but not more than that so we’ll estimate at 40.
Notice for story points of 3 I can estimate the duration down to how many in a given day. For story points in the double digits, my estimate is much rougher.
Now how many times can I drive from Raleigh to Charlotte in a day? Probably twice. So my velocity is two 5 point stories in a day = 10 points. Can I drive the Cleveland route in a day? Nope, but maybe in 4 days. Can I drive the Trinidad route in a day? Yes probably about 3 times.
The next step is to go out and do the work for a fixed amount of time. The first iteration of this type of work is going to be a guess. For example, I’d assume we can do all of the trips except Cleveland in a given week. That’s 19 story points.
Monday, March 2, 2009
The client has requested the ability to search for providers by provider specialty.
The provider search screen shall provide the ability to search for providers by provider specialty.
Use Case Style:
The client selects the provider search screen.
The system retrieves a predefined list of provider specialties and populates the specialty drop down list. The system displays the provider search screen.
The client selects a provider specialty and clicks search.
The system retrieves a list of providers that match the provider specialty search. [Alt 1]
The system displays the provider list result screen with the matching providers. [Alt 2]
End use case
Alt 1: If there are no matches, the system displays an empty provider list results screen with a message: “no matches found”. End use case.
Alt 2: If there are more matches than fit on one screen (currently 15), then the system displays the provider list result screen with 15 matching providers and a ‘next’ button at the bottom of the screen. Refer to “next button pressed” use case.
Search for providers by provider specialty.
As a system user, I need the ability to search for providers by specialty so that I can more efficiently refer patients to specialists.
The provider search screen will have a specialty search box.
The specialty search box will be pre populated by provider specialties (see specialty in the KDB).
Searching via the provider specialty will return a list of matching specialists or a message indicating that there are no matches.
Friday, February 27, 2009
The basic thing about a real story is that it's a metaphor for the work being done. It is not a requirement but a reminder to collaborate about the topic of the story - in other words in agile development (good agile at least), the documentation is secondary to the collaboration. So the story doesn't make you agile, it's the underlying philosophy.
A good story, from our perspective uses the invest model –
Independent – reduced dependencies = easier to plan
Negotiable – details added via collaboration
Valuable – provides value to the customer
Estimable – too big or too vague = not estimable
Small – can be done in less than a week by the team
Testable – good acceptance criteria
But a story is really driven by the acceptance criteria. In other words we try to determine how we'll know when we have satisfied the story before we put any details in it – and we mean actually enough details that we can test the story.
I'd be glad to speak with you in on the phone or via email. Part of my job as agile coach is (surprisingly) coaching agile teams.
Our stories have 3 parts, the title, the description and the acceptance criteria. The description is the only part that can be explained as a reasonable template.
Start by writing the description. It should be long enough to allow people on the team can differentiate it from other stories but short enough to fit on a 3” X 5 “ sticky card when written with a marker. Rule of thumb is that a description should be less than 10 words.
Now write the description. You can use the template below.
As a [user role] I want to [goal] so I can [reason].
Using the description, write acceptance criteria. This is the critical piece of the story. Ask the question “how will I know I’ve satisfied the goal and supported the reason” or “how will I know I’ve done that?”
I'll blog another time with examples.
Friday, February 6, 2009
Friday, January 23, 2009
Agile isn’t free; it comes with new responsibilities, ways of working, and a fundamental shift in principles.Certain legacy procedures and artifacts fall outside of agile, yet interface with the project in such a way as to make the iterative nature of agile development challenging – these are the agile big rocks.
What do you think are the agile big rocks? My candidate list is:
- Performance evaluation of agile personnel – how do you motivate the team and the individual?
- Agile software development within a waterfall business – how do you do small iterations when the business wants analysis, design, code, and test?
- Agile PMO – Can the PMO track agile like a traditional project?
- Scrum failure points – Surely Scrum is not perfect. How can you recognize and avoid failure points?
- Backlog grooming pain points and resolutions.
- Agile forecasting via metrics – how do you plan when you really don’t know what you’re making?
Tuesday, January 13, 2009
I've also found that twitter may be a way to say what you're working on but again, it can limit true collaboration. People tend to rely on the technology. It's a psychology thing - developers tend to be introverted and comfortable with technology (a generalization).
So what do we do? Hold meetings (no)? Get rid of Skype (no)? I'd suggest that we slay the dragon by specifically pointing out that the tool can be a problem for face to face collaboration. Being explicit about the problem can keep people on the striaght and narrow. Face to face collaboration is certainly the highest bandwidth for communication. When you find yourself using Skype too much - pinch yourself and vow not to do that again.
Monday, January 12, 2009
Scrum is not totally lean (of course). We can look at Scrum with a few questions:
- Why do we have 2 week sprints? Isn’t that an artificial and therefore wasteful limit that batches up work?
- Why do we have 7 people on the team? Can we have less (or more) and make sure everyone is engaged appropriately?
- Why do we demo at the end of a sprint and not when the story is complete? Doesn’t this sound like batching work?
- Why do we estimate story points in an estimation session? Some of those stories we may not played because of reprioritization?
- Shouldn’t estimates be done ONLY by those working on a story? Having people that don’t work on the story estimate seems like a handoff situation.
- Why do we work on several stories during a sprint? Can we just work on one and therefore reduce inventories of work?
Friday, January 9, 2009
Do fish burp? I know, fish don't swallow air so they don't really burp from that, but most burping really is caused by the process of digestion - the enzymes, and bacteria in your body that give off air when digesting. I tried to google this but couldn't find the answer. Guess I'll be watching my aquarium more carefully.