RSS

Monthly Archives: August 2010

Agile BI and data warehouses

I have done a lot of data conversion projects and a lot of building of reports on financial information. But when participants in my courses ask about data warehouses my advice is a little more limited.

I usually tell people that data warehouses sound like a good idea and that every company should have one. People usually thank me politely for this but also advise me that they already have one – in fact they have around 17.

At that point we agree that if you use a cowboy based agile approach with no architecture you will add a lot of access databases and tactical databases to the existing chaos without simplifying the environment.  So we agree that we should do a substantial amount of careful design and strategy work before buildng too many databases (ie do up front architecture).

But then one of the group usually reveals that their company also did this and their architects are still trying to convince people that it is a good idea to build $100 million in infrastructure before seeing any benefits – and meanwhile projects are deciding they can’t wait for the utopian dream, so building “tactical datamarts”.

These tactical datamarts generally duplicate both data and interfaces without decommissioning, consolidating or even fixing existing data and interfaces.

So we end up with what is called spagettification driven development.

Even with my limited exposure the business intelligence and data warehouses I can see that this is both the wrong thing to do and an easy trap to fall into.  So a better approach would be to merge detailed architecture (upfront and ongoing) with a continuous delivery of value (new useful reports, simplified data and decommissioned redundant interfaces).

With that in mind I thought I would publish some of the links that participants have sent me to research this further:

An ebook on “agile data warehousing ” that several participants recommended (it will cost about $10)

A RUP based approach published by Scott Ambler

Cutter consorium page on business intelligence

Let me know if you have other links, or better yet some experience in successfully working with the implementation of data warehouses (using agile or not).

Posted by James King

 
Leave a comment

Posted by on August 29, 2010 in Agile, Design Process

 

Sharon Robson – one of the awesome women in Agile

Last month I blogged about the wonderful diversity we have in the Software Education team.

One of our team is Sharon Robson, a passionate and empathic trainer and consultant in the testing and Agile areas.  She was also recently selected as one of the Awesome Women in Agile by the Agile Alliance sponsored Diversity in Agile program.

In the program a number of women were interviewed and explained their Agile journey.  The video interviews can be found here.

We are truly proud that Sharon’s contribution has been recognised and acknowledged for the great work she does.

An InfoQ article about the program  was published here.

Posted by Shane Hastie

 
Leave a comment

Posted by on August 22, 2010 in Agile

 

Tags:

SDC 2011 Speakers Announced

The first group of speakers for next year’s SDC conference have been announced.

SDC runs in Wellington and Sydney in March 2011, with a theme of “Transforming Analysis”.

The first three speakers announced today are:

Johanna Rothman (USA)
Rothman Consulting Group

Johanna is an internationally recognised expert in managing IT product and software development.  She is a consultant, frequent public speaker, and has also written a number of popular books, her most recent being ‘Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects’.  Previous books include the 2008 Jolt Productivity award winning ‘Manage It! Your Guide to Modern, Pragmatic Project Management’; and ‘Behind Closed Doors: Secrets of Great Management’ (with Esther Derby).

Kent J. McDonald (USA)
Knowledge Bridge Partners & Wellmark Blue Cross Blue Shield Health Insurance

Co-founder and current President of the Agile Project Leadership Network (APLN), Kent specialises in successfully applying pragmatic approaches to strategic planning and coaching business analysts and project managers.  Kent is co-author of ‘Stand Back and Deliver: Accelerating Business Agility‘, a book that brings together immediately usable frameworks and step-by-step processes that help organisations deliver business value and build competitive advantage.

Steve Adolph (USA)
Agile Coach, Rally Software

Agile Coach, co-founder of Agile Vancouver and published author, Steve is passionate about helping organisations get the job done.  With a long professional career involving business-critical projects such as the design and development of leading edge network management systems, Steve is an expert when it comes to teaching others about business modelling, requirements analysis, software architecture and design.  He is co-author of Patterns for Effective Use Cases”

The full press release can be found here

Posted by Shane Hastie

 
Leave a comment

Posted by on August 17, 2010 in SDC 2011

 

Tags:

What makes a “good” story

This morning I received an email that asked how a team will know their stories are good enough?

This question is one that frequently comes up in classes, and the right answer (of course) is “it depends”, which probably doesn’t help you much 🙂

So – what does it depend on?  Here are my thoughts . . .

The most common structure for a user story is

  • As a <role> I want <feature> so that <benefit can be achieved>

It’s important to carefully evaluate each component of the story –

  • Role – Who needs this feature from the system,
  • Feature – A succinct statement of the need
  • Benefit – The business benefit that this feature will deliver, this must be traceable to the project goals and objectives

It is important to remember that a user story is not intended to be the detailed requirement – it is a “placeholder for a conversation”.  A story has three C’s associated with it

  • Card – the statement of the business need
  • Conversation – the elaboration discussion that happens shortly before the story is ready to be implemented, this conversation will flesh out the detail and allow the team to build the third part the
  • Confirmation – the elaborated details that form the basis of the test cases and confirm that the story has been delivered

The “Card” is the one-line statement of the feature to be delivered, often in the “As a … I want … so that” format.

The “Conversation” component of the story is how the detailed requirements get identified – the conversation happens shortly before the team is ready to build that piece of the product.

The “Confirmation” component makes up the acceptance criteria that will show if the story has been implemented correctly.  The test design criteria that are agreed to when the conversation happens.  Defining the confirmation criteria is how the detailed requirements are expressed – this could include screen mockups, technical design details, quality guidelines (performance, security, usability …) and any other details that will help the team build and test the feature into the product.  The minimum confirmation criteria that should be included are a set of test designs, often expressed in the Behavior Driven Design format of “given … when … then”.  I’ll examine this in more detail in a later entry…

A good story is one that identifies the piece of functionality or quality to be delivered at a level that the business representatives on the team can prioritise and the technical team members can estimate.  It should be small enough to be understandable and convey the business benefit without needing detailed explanation.

How small is small – a rough guideline is four days or less of team effort to deliver the story on its own.  Not taking into account any “plumbing” or architectural work that needs to be done to enable the functionality.   Team effort means all the work that needs to be undertaken to deliver the story to the “done” state – whatever analysis, design, development, unit & system testing  and user acceptance testing is needed.

Here are a few example stories, and some ideas about them

As a book reader I want to buy my ebooks online so I can read them whenever I want

Large stories such as this are often referred to as Epics – an epic explains a large business goal, but is way too large to estimate effectively, and very difficult to prioritise.  Epics are OK in a story list, as long as they are not high priority items – an epic that is high priority should be broken down into usable stories before so they can be estimated and prioritised.  Low priority epics remain in the story list until shortly before the team is ready to work on them, then they need to be expanded into usable stories.

As a book owner I want to see a list of the books in my online library sorted in alphabetical order by author or title or date purchased and be able to dowload them in a zip file so I can read them on my iPad

This story is complex and imposes unnecessary constraints on the way books are sorted and downloaded.

As a book purchaser I want to store my reading preferences so I can receive recommendations about books I might enjoy

As the company accountant I want purchasers to pay for books using PayPal so that we don’t need to set up credit card facilities

As a book owner I want to select the download file format so that I can read my books on multiple devices

These stories are about the right size and structure.

What advice can you offer to teams working with stories?

Needless to say, these concepts are not original thought – Mike Cohn, Ron Jeffries, Kent Beck and many others have written extensively on these topics, and I’ve been fortunate to be influenced and informed by their work.   A fantastic book that describes many of these concepts is Mike Cohn’s  “User Stories Explained – For Agile Development”.

Posted by Shane Hastie

 
5 Comments

Posted by on August 4, 2010 in Agile

 

Tags: