The History of the Internet

Found on Youtube.

Naturally being a bunch of technophiles you'll already know this, but it is well presented.

Enjoy.

Bet your chips

I am going to try something new with my team to help them better self-manage. It an idea goes nicely with planning poker.

Next week I am going to take in a bunch of poker chips to work.

When a decision deadlock happens we'll put down a time limit. We'll have a rule that goes something like 'no more than an hour (maybe 2; they like to talk) of discussion on a topic and then if the dispute can't be resolved by negotiaion, rational argument or consensus you have to bet your chips or fold.'

If you fold, you the other person wins the argument and you must follow their proposed path forward, until it turns out to be infeasible or an actual significant problem. With tangible effects.

Naturally, the highest bet wins.

But the loser gets all the chips that were bet. That way (so my theory says) everyone gets a turn at winning intra team disputes. And everyone participates in owership of the deicions and of the solution.

Learning from mistakes is fine. We make plenty so we have plenty of opportunity.

Group ownership of the solution - everyone taking personal accountability - is the real win.

Anyone heard of this being used before? Got an opinion?

I wonder of the team will go for it?

(This is an idea I have been wanting to get to for a while. I was remined of it after reading a post a Noop.nl.)

Photo by Wafler CC @ Flickr.

A project parable

A nice little story for a Friday afternoon
Rocks Into Gold - Helping Programmers THRIVE through the Credit Crunch - by Clarke Ching

View more presentations or upload your own. (tags: chain critical)

Seeking feedback from regular readers

Asking your customer is one great way to customise your offerring. Peer review is an excellent QA tool.

So regular reader, help me out; Tell me what I am doing poorly (and well if you like) and what changes you'd like to see here.

Thanks in advance :)

Object oriented requirements and iterative development

If you are articulating your requirements in a way that is able to be delivered in multiple iterations you are probably trying to deliver a series of releases with valuable and useable features to your clients.

There appears to me to be a tension here between an object oriented approach to requirements definitions and breaking the parts into useful components. It won’t always rear it’s head, but it’s going to be lurking in the vacinity.

You may have a set of generic functions you want a sales website to provide. Examples may be “present products,” “make sale,” “take payment,” “produce order,” “fulfil order” and “produce reports.”

And say you have four products you sell which all require customisation at each leg of the process. They may be presented from different inventory systems, require different payment methods, or whatever.

How do you arrange your releases? Presumably the fastest way to get revenue flowing is to build the end to end process for one of the products.

Then how do you address the way the requirements are focused on functional requirements?

I don’t have the answers to this question. I do have a hunch, which suggests that you as the requirements manager need to put in the extra work to un-abstract the requirements (if you know what I mean) back into a pragmatic application of the system and process. I think this may mess with the BA concept of diving the requirements and solution cleanly.

What do you think?

Photoi by Dey, CC at Flickr

Product roadmaps versus product blueprints

The blueprint is the end state. The roadmap shows changes to the product over time, focusing on major milestones, which will often align with system releases.

The roadmap provides the opportunity to articulate the solution at different states in it’s lifecycle. An example may include a data entry screen being built with no validations, and then a later release with field or data validations being introduced. Maybe the back office user data entry process will get decommissioned and replaced with a web based customer data entry process.

A blueprint is the idea of a defined product via a set of requirements and/or features. It shows an ‘end-state’ for a product. The blueprint is fine of you are only targeting a project with one major release, but that is likely to be the exception rather than the rule these days.

BAs who are working on projects with multiple releases (or iterations) should be working to parcel their requirements into these product milestones. Adopting the agile philosophy of early value through many releases you also get the idea of ‘value management’ embedded into your requirements management process.

Picture by Ricketts Fish CC at Flickr

Seth Godin's 5 pillars of success

Godin published a list the other day.

His post;

1. See (really see) what's possible

2. Know specifically what you want to achieve

3. Make good decisions

4. Understand the tactics to get things done and to change minds

5. Earn the trust and respect of the people around you

It sure seems like we spend all our time on #4.

And yes, we often focus on 4. (We also spend a good deal of time and effort on 1, 2 and 3.)

Definitely item 5 could do with more investment, don't you think?

PDOOMA

P'DOOMA - Pulled directly out of my ass.

A common and (cost) effective way to estimate projects.

Pic care of coderkind, cc @ flickr

Business Model Frameworks extended

Alex Osterwalder's business model framework now appears to have an electronic tool to support it.

I think the business model is a great first step in the requirements management or project scoping processes. I see that it helps clarify the top line expectations about how your solution is supposed to fit into the organisational context and align with it's goals.

You can read about the tool's development here.


Business Model Designer From Sticky Note To Screen Interaction Presentation - Get more Business Plans

The Data Management Body of Knowledge (DMBOK)

ModernAnalyst has published an introductory article to the Data Management Association's Body of Knowledge.  It's another BOK to add to the list!

The DMA is almost 3 decades old, so while it is new to me it appears to be a substantial organisation.  They even run a certification programme.

(Scott Ambler what are your views on them?  Dinorsaurs?)

The DMA's framework is articulated in this diagram.   I hope it intrests ou enough to go and explore. 

• The full article is here.
  

Agile Case Study; Salesforce

Salesforce.com Agile Transformation - Agile 2007 Conference

View SlideShare presentation or Upload your own. (tags: agile salesforce)

B2T's thoughs on Agile

B2T are a training organsation that focus on the BA skill set.  They have a BA blog which is worth reading.  This week Kimberly published some thoughts on Agile - a reassurance that the BA role is still important, even with the rapid growth of Agile methods for projects.

It stimulated some thoughts of my own.

1. BAs are not required for all types of agile projects.

In fact if the developer team have the skills, why not let them out of the back room onto the shop floor? Why put middleman into the conversation?

How you address requirements management depends on the project, the people and the organsiation. BAs are not always required. (Nor are programmers.)

2. Iterations mean you don't work to a product blueprint.

If you are a BA assigned to an agile project your most likely mistake will be to model an end state (at least in your head) and then work towads that. This is pretty much contrary to the whole iterative approach.

There is a fundamental value in the agile philosophy that says if we design a product today we will probably get it wrong. So don't. (The phrase that is disparagingly used is BRUF.)

In many stable markets - such as governement - this is not true, but in environments where thre is significant shift in business requriements over time, it is very important to understand.

3. You will probably not work on a pure agile project.

The world isn't black and white. And you don't just pick Agile or Waterfall approaches. In the real world you usually mix it up, pulling techniques and tools from a range of methodoloies and frameworks to address the specifics of your project.The approaches us enterprise workers will usually take is a compromise - some of the strengths of agile and some of the strengths of a plan diven approach.

Part of this creation of a hybrid approach is because we think about the situation and design an approach that is appropriate to the cirumstances. Part of it is becasue of a natural conservatism in large organisations.  (And I think that at this stage of the Agile methodology maturity we don't know whether this will be a compromise or an enhancement to the agile models.)

And lastly, I think when people talk about Agile as a methodology is smacks of a certain lack of understanding. (Maybe on my part?)  Agile is a value set which underpins several (dozen?) methodologies.  As a BA, when you talk about Agile I expect you (readers of BetterProjects) to be more specific.

Innovation and delivery

I've been reading a book of car reviews by Jeremy Clarkson of the BBC's Top Gear. In his review of the Mercedes Benz CL65AMG he kicks the article off with a run down of some of the technological advances that occurred during WW2. And then reminds us that The War ran for only 6 years - the duration of a typical 'challenged enterprise transformation" effort.

What is it that makes change so hard in our world? Why do stakeholders introduce so many complications? Why do products get built with so many extraneous features? What, as an industry, are we doing wrong?

Anyway, Clarkson quite liked the car.

Serving your customers

"Don't buy into this crap that IT is a business within a business serving internal customers. There are no internal customers... Everyone within the enterprise is a part of a team that should be working together to satisfy customers and stay in business."

So says David Wright, author of "Cascade; Better practices for effective delivery of information systems in a multi project environment."

David, on the one hand, I take your point. On the other, as I manage my personal career, I think I have to consider the people who pay my bills, who refer me new work and who recommend me to otehrs as my customers before the enterprise's actual end-user customers.

For two reasons;

The first is that my career has and will continue to span multiple businesses and multiple industries. I am an itinerant professional. Once my job is done, I move along to a new problem at a new company. And I act as a ub-contractor, so I have some responsibility to deliver to the brief, regardless of whether that is what I belive the customer really wants. (I do tend to share my opinion though.)

And these days we pretty much all expect to change companies every few years. And why not? We can do a better job and get better rewards if we come with more breadth of experience. So we move around. ANd so hiring managers are our customers.

Secondly, unless you are in charge, you can only usually chip away at the problems enterprises have with their custoemrs. And when you are in charge you are steering from a long way above sea level, so you can only influence outcomes via your management team. As a project person, your potential scope to make radical change is limited to specific areas at a time. And usually you are operating on one of the senior leadership's initiaitevs, which should be a major cutsomer/performance related issue, but isn't always.

Thoughts?

Photo cc at flickr

Jurgen on Methodologies

Jurgen writes on one of the more popular blogs on software development in Europe.  Recently he wrote a post summarising a bunch of popular project and development methodologies.

I've moved it into a powerpoint for a presentation.  It isn't complete, and the views on the methods are his, not mine.  If you have comments on what he has to say, I'd love to hear them.

Software Project Methods

View SlideShare presentation or Upload your own. (tags: software agile)

"What took us a weekend to do, has taken 18 months here."

There is a difference between the enterprise BA and the software product manager.  And there is a difference between requirements management in the two contexts.

The title of this post comes from an article from Jim Stogdill at O'Reilly.  Jim, like me and most of the readers here, is an enterprise IT worker, and has some ideas worth reading about the different environments enterprise and product IT shops operate in.

In particular I want to draw your attention to the comments.  Especially one by Thomas Lord, who seems to be speaking as a VC person.  The comment is a mix of economics and business model ideas that will make you reflect on how things could be better at your compny.

Lord's advice is to seek improvement through capability (possibly through better leveraging your people) and increasing the range of products they are able to develop (and my take on this is through architecture.)

I hope you like it.

Picture by [togr] CC @ Flickr

On writing requirements

Here is an interesting presentation on writing requirements.  Most of the material has been gleaned from pragmatic marketing, so you can dig further there.
 Requirement Writing for Product Management

View SlideShare presentation or Upload your own. (tags: development design)

Pathway to Requirements failure

Cauvin writes a post about one of the many ways that requirements failure can lead to customer dissatisfaction.

Usually when thinking about customers we can think of end-users of a company's products or services, or the sponsor (or whoever is paying you.)  If you think like that you usually focus on what is most important.

Sometimes (okay, usualy) you can get stuck dealing with the stakeholders wants and needs and they become the focus and the main part of the work involved in getting to the right solution.. It feels like the pareto principle is at work, and that's a trigger for optimisation.

To streamline the amount of non-trival, but non-core requiremets that you need to deal with you can try any number of requirements categorisation techniques.  My current favorite is ranking requirements.

It is an excellent prioritisation tool, facilitaes iterative development and helps senior management's goals be put in the right context in relation to middle and front-line management goals.

Frankly, it gets a good conversation going among business stakeholders, top to bottom.  And once you have an aligned vision of the product amomng your business stakeholders, many of your potential project problems are resolved.

Photo by Bashed CC @ Flickr

Use Cases and User Stories

For a few months now I have been trying to work out whether I should be running with use cases or user stories on a hybrid XP/Scrum/Prince2/Waterfall project.

User stories are attractive because they are part of the XP toolkit and are lightweight and easy to implement. That rolls well with the team members who have had several bad waterfall project experiences and want to turn their backs on the way they used to do things.

Use cases provide context and a more holistic view of a product. They also require more discipline to put together and more time to complete. And they are less complimentary with a just in time requirements inventory. The Use cases the team are used to dealing with are also very abstract, so sometimes it is hard to get a feel for the tanglible feature set being developed.

There are strengths and weaknesses to both, and possibly the biggest issue to consider is which toolkit is the team best able to work with. I don't have an answer to that right now.

Of couse Alistair Cockburn does.

He's a fan of something he calls Lite use cases, which he links to in his post. Take a look and let me know your thoughts.

Photo by ntr23 cc @ flickr