31 August 2011

methodology: use cases, user stories and acceptance tests

While doing some research into user stories and use cases I came across the below article by Jens Coldewey.  The original is in German, and with the help of Translate.Google I transcribed the post into English.

The original article is here.

Methodology: use cases, user stories and acceptance tests, by Jens Coldewey

What is the methodological difference between use cases and user stories? I have not worked very intensively with Use Cases, can therefore only reproduce what I expect from my understanding of Alistair Cockburn's explanation:
A user story is ultimately the title of a scenario, possibly together with an example. Several scenarios are a common use case. 
Can we, as Agile sophisticates use Use Cases, or must we stick to user stories? The question is of course nonsense, because in agile development it is not about what you "should" and what is not allowed, but how we can best achieve a goal.

The goal in this case is an adequate understanding how the system is to be used, and thus the implication for its design and construction.

I personally like to see use cases as the technical design. As with the technical design, there are two possibilities: One can specify the design before implementation, at least in broad outline, or it can arise during the implementation in an "emergent" manner. So you can create your Use Cases prior to implementation or as you evolve the system, building the model to reflect the system as it emerges.

 Ultimately, the result of the analysis but must be available and useful. If you are using XP style acceptance tests they should cover all relevant user stories, and therefore all relevant scenarios of use cases. With regard to notation for the individual tests Brain Marick wrote some thoughts worth reading in his blog that deals with a little good will and skill with FIT or FitNesse can be implemented.

How much analysis is required in advance - therefore how much use case analysis - depends, among other things, on how well the product owners, acceptance test-writers, analysts and developers feel comfortable. It should also be remembered that it is often much harder to refactor acceptance tests, than to develop "real" code in an emergent way.

In no case does preliminary analysis warrant the return of the thousand-page technical specification. Both the ideas of “as much as necessary” and “as little as possible” apply. Many of my clients were very happy with five-to ten-page analysis documents, whose core was often driven by use cases. From this foundation the individual user stories are defined and prioritized, the acceptance tests defined and the code implemented. The additional work was rarely more than a week.

Alternately, other teams have worked from bottom to top but at the end the user stories are grouped according to use cases. (Even so, the Use Case structure is often initially captured on a whiteboard.) I myself have not found a reason to work for one way or the other side as long as the correct result is obtained.

[end of translation. Read the comments on the original post here.]

Have you got a KPI around lunch?

29 August 2011

Kanban conversation

A Bicycle for our Minds

This is exactly the same reason I enjoy being a BA that works with technology.

23 August 2011

Two articles that have inspired me

Been a busy couple weeks at the day job, so my writing time has been dramatically reduced. To tide you all over until I can return to writing (hopefully this weekend), I thought I'd share with you a couple quotes from articles I've read recently that have inspired me.

First up, Alan Cooper, who I've shared with you guys before:
You can't save your way to creativity. Creativity isn't necessarily expensive, but it's a human rather than industrial activity, and when you put external cost constraints on it, you put it in an artificial box that simply kills it. Creative people need unfettered time and attention to solve difficult conceptual problems.
Remember this quote the next time you're told to 'think outside the box' and then are told 'we need this by tomorrow morning'. Sometimes the 'spurs' can get an answer, but it is hardly likely to be the creative one you really need.

Next up is another designer, this time a new person to me, by the name of Craig Grannell.
Only by embracing new technology and then seeing what we can do with it can we ensure we don’t remain stuck in the past. And for everyone moaning about the lack of obvious utility in tablets, people once said the same thing about computers—and look where that got us.
I was the first person to roll my eyes when the iPad was announced. Nice toy, but it will never replace my laptop. I just don't have a use case for it, I would say. You can't create on it, pundits would scream.

Guess which computing device goes with me to 90% of meetings now? You guessed it, the iPad. The only time I take my laptop is when I need to host a webinar or display a secondary screen while taking notes.

People, and I, myself was at one time included in that vague generalization, misunderstand the point of using tablets to create with. We're concerned with creation as it is defined today, not creation as it will be defined 10 years from now. Tablets are ushering in a completely new way to be creative; they are not intended to compete with what we call creation today. Its been less than a year and a half since the first non-PC tablet was introduced and the ways people are using it to create blow my mind. I can't wait to see where it is 10 years from now.

22 August 2011

#AgileBA and Behavioural styles

Our local #AgileBA community meets monthly, and we finally videoed an event. The Slidedeck that goes with this presentation is below.

Will Mentors Jump the Shark?

Mentoring is a popular technique these days.  It's an acknowledged improvement on traditional management approaches to professional growth as it includes ongoing learning, mentee directed learning, the freedoms to explore what's important to the mentee rather than follow a structured programme, and more.

But like all practices that grow in popularity, the average value of a mentor will degrade in proportion to the quality of practices employed.  When new (and it's hardly new) practices grow to become popular they are no longer the exclusive toys of early adopters who tend also to be intelligent on a number of fronts including intrapersonal ones.

So what is the secret sauce in the successful mentor relationships?

I keep hearing that "we learn from each other."  A good mentor gets as much from the mentee as they give.  And a good mentee knows and appreciates the mutual trade.

Have you got a mentor?  How long has it been going?  How is it working for you?

19 August 2011

Practice with Scrum

  • Athletes practice their skills; practice, repeat, fast, slow, different conditions, etc
  • Scrum gives people an opportunity to practice the elements of the SDLC
  • The timebox is the anchor of this learning/improvement aspect
  • Sprints bring a regular rhythm or cadence that provides a structured and safe backdrop in which to experiment and learn
While Kanban proponents advocate evolutionary change it might lack the rhythm that helps people learn effectively.  On the other hand Kanban enthusiasts talk about the need for cadence to help the team work effectively.

Maybe Kanban laid over Scrum would be a better implementation than Kanban laid over Prince2.

Having said that, maybe Kanban is a better model for getting work done once you are ready to move off Scrum's "training wheels."

11 August 2011

Warring Against Organizational Failure

I'm not a fan of Michael Arrington of TechCrunch. Leo Laporte, famous face in technology circles and all around really nice guy, doesn't think very highly of Michael, either. (Warning, a small bit of NSFW language included).

It takes a lot to make someone as nice as Leo get that mad. Still, even a jerk like Arrington can, on occasion, really get something right. He did so recently with this piece on why the expense reporting process at his parent company, AOL, is so terribly restrictive.
Last night, for example, I was cleaning up my desk. I have an envelope I keep business expenses in. There was a hotel bill for a trip when my AOL issued credit card was turned off for the day. Some taxi expenses and a restaurant bill. I looked at them, thought about the process for turning those expenses in and then having to defend them via a phone call (Heather would probably save me from this, but there goes an hour of her time). So I did the rational thing. I shredded those receipts – around $1,500 – because it wasn’t worth the pain.
I don't feel much sympathy for a guy who has enough cash on hand to just toss out $1,500 worth of legitimate business expenses paid for out of pocket, but were I in that same situation with those kinds of bills for a single day, I would have moved heaven and earth to get that reimbursed. What did get me was why AOL has such draconian policies:

Then today I was talking to someone at AOL about nothing in particular, and he brought up his own troubles with expense reimbursement. I asked why the company is so crazed about it. 
Enter Gregory Horton. This guy was head of HR at AOL a decade ago when the company was still part of Time Warner. His story is amazing. He apparently set up a dummy consulting corporation and was billing AOL $100,000 a month for made up work. All in all, the company lost over a million dollars to Horton, or so the story goes.

This reminded me of one of my former employers who had policies as absurd, yet in a different way. I once had an expense report worth about $6,000 (three weeks in France) rejected causing the payment to American Express to be late, resulting in a late fee. Did it get rejected by the hundreds of dollars of wine purchased at multiple dinners? Nope. What about the multiple hotels I had to stay at because rooms were hard to find (and expensive) for those weeks? Nope. Surely it was the last minute purchase of an airline ticket! Nope.

A $2 parking fee was missing from the receipt packet. No, I am not kidding.

At some point, you have to just wonder about what rule someone broke 10 years ago that would cause so many process controls to be put in place that would reject an entire expense report because of a receipt that was completely immaterial to the larger goal of my project. So when the late fee came in, that I was responsible for, what did I do? Its called inflating costs on my future expense reports to cover the late fee caused by idiotic processes.

Was that underhanded of me? Most assuredly. Yet, if you look at how poorly the rules were instituted, they were giving me incentives to monkey with the system. If someone had bothered to think about how trivial that parking ticket was when compared to the total of the expense report, there would have been a 'minimum % rule with a maximum value rule' instituted that would weigh the time it took to fix the missing data and the potential late fees against the value of the receipt. Its an adaptive rule that recognizes people's time and that some things simply are not worth arguing about.

Its situations like this that we, as project people, need to remember. We're the ones who are looked to as trusted advisors by our business partners and its our job to make sure bad rules like this are caught before they are institutionalized. Work with me to fight for the rights of our users and fellow employees. Down with bad rules.

10 August 2011

Last week at #pmoz...

I had a great time at the combined PMOZ and ISSEC conferences last week.  Among other things I met Richard Turner and had some interesting conversations with him about the Kanban and systems thinking movements.  I also got to play GetKanban which was fun and informative.

Another highlight was having beer and dinner with OneFTE.

But the best bit was when I took a backward step during my talk and fell off the stage.

In this presentation I talk about Requirements Traceability, flowing work through the delivery cycle in small batches and using the traceability practice and tools to develop progress reports in the form of cumulative flow diagrams.  It's lean, agile and CMMI practices all rolled into one sweet little package.

9 August 2011

Russell Ackoff on Analysis

I have been watching 'systems thinking' clips on Youtube and the most recent one (part 1 of 3 below) made me reflect once again on the role of the business analyst.

For the uninitiated the simple summary of Dr Ackoff's message in this speech is that you can't use analysis to understand a system.

Analysis, per Ackoff, is reductionist.  You break something down into it's parts and understand the parts. By doing this you hope to understand the whole.  What we need is to apply systemic thinking; understand the parts in relation to the whole.  In fact we should invest our efforts to understand the system the parts are a part of.  This way we understand the whole system and can improve it. The implication is that if we don't do this thinking we end up tinkering. And maybe even degrading the system.   Examples that illustrate the point pepper the half hour talk.

When a business analysts tackles the work before them, what do they do?  Do they tackle it via Ackoff's definition of analysis - break down the object and then try to understand how it all works through decomposition?  Or do they apply systems thinking to the whole system they are working with and think about how the parts interact and relate together with the system they play in?

Different analysts apply decomposition, contextual and relational thinking... and sometimes both.  Complex systems, for example can be very difficult to understand through decomposition.  Complicated systems can be difficult to understand without decomposition.  Complex and complicated situations probably need a combination of analysis styles.

Reflecting as I write I see another "it depends on your circumstances" answer forming, but in reality - if we want consistent project outcomes - we need to have the capacity for both and the judgement to know when to apply the various thinking models.

What's your analysis of this thinking?

8 August 2011

Eating Rotten Fishheads

I've blogged a couple times about Alan Cooper in the past, and will likely do so again in the future. One of his recent posts, from his company's blog, had a really great quote I needed to share with you all:
I do not believe Microsoft's assertions that the ribbon is easy to learn. If you feed someone rotten fishheads for a while, then switch them over to a diet of fresh fishheads, they will be happier. You can then tout the statistical "fact" that "users prefer fresh fishheads," even though the truth is that they HATE fishheads. That, I believe, is how Microsoft gets its rationale for UI changes.
Cooper is discussing his recent switch from Office 03 for Windows to his new Mac. He hates Office's ribbon interface, his point being that Microsoft's claims of it being easier to use than the old interface is bogus. I agree.

His broader point though is that if you're changing something from bad to merely less bad, you shouldn't go around telling everyone about how great the new is. Its not. The cognitive friction you force on your users with a completely revamped interface is not worth it when your improvements are so minimal compared to the learning curve.

This came to mind as the meeting I sat in all day today spent a significant amount of time discussing the look and feel requirements for a new application we're considering having a vendor create. Our current system uses a series of accordion menus down the left-hand side of the screen. Last summer, when that system received an upgrade, the new version allowed for pull down menu navigation across the top of the screen. Assuming that people were likely more familiar with that type of navigation, the default was switched to the pull down menus.

It was resoundingly hated.

See, the new navigation style really wasn't any better (or worse) than the left-hand menus, it was just different that what people were used to using. Had the new navigation system been substantially better, maybe with large icons that can expand out into sub-folders, such as is seen with the iPad, then maybe the user outcry would have been much less.

When you're looking to change something that is a known quantity for your users, always make sure that the change is really worth it to your users prior to making. But how do you know the change is worth it?

First, ask around to see if anyone is up in arms about it. Don't ask subjective questions like, "Do you like navigation?" but ask more focused questions such as "Do you like left handed navigation or menu bars?" You're more likely to reduce the 'noise' in answers and get to the real meat of the discussion. The flip side of this advice is to make sure you really do touch on areas that could be of real concern.  If you miss asking about the real problem, you wasted everyone's time and are no better off than before you started asking questions.

Next, place a value on the change. Does it save your stakeholders a lot of time? A lot of money? A lot of frustration? Define what 'a lot' really is! If you have 10 users and your change will save them only a few seconds a month, it probably isn't worth making the change UNLESS it removes something that is so incredibly annoying that you build a lot of good will. On the other hand, if you have 10,000,000 users and it saves each of them a few minutes a month, then the value of the change is very high.

Now, determine the cost of the change. There are lots of costs here. If its a system change, you've got to calculate the cost of the stakeholders to explain the desire, the analyst to figure out the best way to fit it into the existing process, the developer to code it, the testers to test it and the Ops team to deploy and support it. Your users will need to be trained on the new function, that will add to your cost. If the process change is significant due to a vastly changed process, will they be able to learn it and do so quickly? Don't forget about the opportunity costs, either. While you're making this change, what other changes are you forgoing that could be less costly?

Finally the hard part... determining if the change is really worth it. You take the value, subtract out the cost and see if you've got anything left. Even if you come out with a positive value here, remember that if the value is very small, then it may still not be worth it. The goal here is to provide your stakeholders with a significant positive value, one that is large enough to overcome their fear and reluctance to change.

Change #1

As you know I signed up for a new job recently.  In week 1 I met the team and a  few stakeholders.  Then I went away for a week to PMOZ.  Today, my first day of week 2 I broke down and implemented my first system change.  I thought I would share it here.

Change #1 was a horizontal line on a whiteboard with a series of marks representing the fortnights between now and December 30.  I then asked the project managers to turn up and place post-it notes onto the board with significant deliverables and activities from their projects.

This will likely be a catalyst for a portfolio (of about 8 projects) stand-up meeting where we look ahead into the immediate future and focus on risks and issues and face them collectively.

We'll see what happens.

The important think is that it is a small change.

4 August 2011

The US Postal Service... Reloaded.

Part of me feels bad, picking on an organization like the USPS. Then the rational part of me steps back and realizes, who better than to take on than an organization with so many problems. Who else is in more need of some new ideas?

The organizations issues are numerous:

  • A large debt load in the form of 31,000 local offices
  • A large pension fund to maintain for retired employees and future retirees
  • A declining revenue stream
  • A mission to serve all parts of the US, even those that are extremely remote and vastly unprofitable.
  • A workforce that works more days (six) than most citizens (even if their days are often shorter than the standard 8 hour day)
  • Increasing direct costs in the form of increasingly expensive gasoline
  • Declining usage due to many of its core customers moving away from print and to digital distribution
I could go on, but I think you get the idea. So now I would like to float a few ideas that I think might help the postal service survive, or even thrive, in the future. I'm definitely not an expert, although my day job does give me a lot of knowledge about the economics of delivery, but that's actually kind of the point.

To structure my ideas, I'd like to focus on a coupe classes of ideas. First up is cost reduction:
  • Restructure your pension fund. Take a lesson from the automotive companies and pay out a lump sum to some other entity to pay for retirees. Its painful in the short term, especially since you are already deep in debt, but it frees you for the future.
  • For decades, you've invested in OCR technology to help you sort mail with less human involvement. Progress has been slow, but you're getting there. Make it better; partner with someone who has done a lot with OCR recently, namely Google. Yeah, their email application is part of what's killing your business, but if anyone knows how to interpret the chicken scratch we call handwriting today, its probably them. Yes, they will exact a price from you, most likely in terms of access to wire up your delivery vehicles with tracking devices for multiple purposes (traffic patterns, better street maps, whatever), but you've got to make a deal somewhere and these guys are the least of your bad options. In the end, get your sorting process up to an unbelievably high standard.
  • Don't like my OCR idea? Fine, kill stamps. Make all postage required to be digital. Make people enter the delivery address on your website (or self-serve kiosks in your retail locations) and print postage on demand. Make them 3D barcodes. Do whatever you need, but kill stamps.
  • Speaking of kiosks, add more to your retail locations and make the software not suck. I can figure it out myself if you guide me through it. I figured out the self-serve checkout software on the ATM and at the grocery store, I'm pretty sure I can do it for my package as well.
  • One area I can't really fault you in is package routing efficiency. Sure we could all do better, but you're pretty good. Learn from the Japanese car companies; make small changes, continue to tweak and drive out costs.
But cutting cost is only half the battle. What about revenue?
  • You've got great retail spaces. Use them. There's a reason FedEx purchased Kinko's and that UPS purchased Mailboxes Etc. Learn from your younger siblings; expand your vision. Don't make the run to digital like your failed attempt to be an email gateway in the 90s.
  • Two words: premium services. Which ones? I have no idea. Maybe have Lady Gaga lick envelopes for anyone willing to pay $1000 to mail a letter. I'm leaving this one up to you because frankly, I'm drawing a blank. Doesn't mean it isn't a good idea, just not one I have a good grasp on. You've got smart people, I'm sure you'll figure it out.
  • Partner with those who are competing against you. Carry packages for UPS and FedEx, especially in those really remote areas they don't want to service but you are required to. Charge them through the nose for it, too.
  • Win some sales deals. There is a reason amazon.com delivers at least once per week to my house. When I polled my coworkers, my number of shipments was pretty much average for the group. Yes, you already deliver a good number of their shipments, but do more.
Yes, many of the things I suggest are outside of your mandate or outside of your traditional offerings. That's the way of the market. You've stood still too long, doing what you've always done, but times have changed while you have not. There is one more thing you need to think about... what happens after your mission is over?

Don't get me wrong, people will always need to move physical goods from one location to another without making the trip themselves. But your mission, delivering mail everywhere, will end, if for no other reason than everything ends at some point. What plans have you made for your organization when that day comes?

The time is now to invest in the future. Innovate. You can do it; you've got the people and the history, you just need to make it happen.

1 August 2011

The Ultimate Productivity Blog

I give you all, The Ultimate Productivity Blog.

Now that you've read it, how do you respond to it?

I ran across this reading Jeff Atwood's Coding Horror blog. He went on to say:

Reading self-help advice from other people, however well-intentioned, is no substitute for getting your own damn work done. The sooner you come to terms with this, the better off you'll be.
Get out there and do stuff because you fundamentally enjoy it and because it makes you better. As a writer, as an analyst, as a techie, whatever. Learn to love practicing the fundamentals and do it better each time. Over time, quality does lead to success, but you have to be patient. Really patient. Turns out, "overnight" success takes years. Maybe even decades. This is not a sprint, it's a marathon. Plan accordingly.
I couldn't agree more.