Archive for the ‘Scrum’ category

« Older Entries

Open Sauce

October 9th, 2009

Time Management, an ugly phrase that we all know just doesn’t apply to us, right?  But what about when you’re buried in some complicated ETL, trying to design a new killer dimensional model or wrapping your head around how to implement a Kimball bridge table.  You get a bit stuck and then your mind wanders, you check your email, send an IM, chat to your co-workers, think about getting a coffee etc etc.  If you really never do that then stop reading now (but why are you reading this?).

Thought so.  You need The Pomodoro Technique.

pomodoro

Like all good things, this one is founded on a really simple concept.  Just focus on something, above all other activity, for just 25 minutes.  Then have a 5 minute break.  That’s a pomodoro.  Then repeat x 4, then have a longer break.

Try it. It’s surprisingly difficult for a lot of people, it seems that we tend to operate in an environment with a lot of interruption and distraction.  Francesco Cirillo worked this all out at university in the 1980’s and came up with a method of improving concentration and motivation which seems to have gained a huge following just recently.  I’m interested because it sits well with Agile and Scrum and BI/DW development (time-boxing and and the productive work/play dynamic).  If you read all the documentation you’ll be doing better than me but Cirillo would appear to have seriously researched this stuff.

The ‘internal interruptions’ are the thing that I probably suffer from most - it is actually quite comical when you think about it.  Why all of a sudden, at a particular moment you just have to look something up on the Internet, or make a phone call, or send a text message?

The solution to this procrastination issue, and one of the main benefits of Scrum are the same.  Make the issue transparent.  Just as you would identify and mark an impediment or a newly-emerged requirement as a backlog item in Scrum, so you highlight the existence of the interruption or the pressing need using the Pomodoro Technique.  I think the underlying message is the same - we operate in a dynamic environment so lets recognise and accept that but not let that unduly influence our progress or our short-term plans and goals.  Just as a Scrum sprint is short, so is a Pomodoro.  Lots of short iterations = higher chance of successful delivery which in turn increases satisfaction, motivation and belief.

We do actually have one of those pomodoro kitchen timers in the office now.  Its pretty noisy but probably preferable to an electronic screen-based timer in terms of impact and gained respect.  If you just can’t stand the idea, or can’t find anywhere to buy one (try eBay) then you can download all kinds of timers online, some specifically aimed at this technique, but give it a go, you might be surprised what you discover.

No comments »

Posted in Agile, People, Scrum

Value driven IT?

September 12th, 2009

We all want to do new cool stuff and not worry about the more boring IT stuff.  I dream up at least a couple of new ideas a week that I’m convinced would be worth investing some time in but I rarely get to prove them because of the more boring IT stuff that just has to be done.

Well I actually think we need to do new cool stuff and not worry about the more boring IT stuff.

One of the principles of Scrum is that the work you do is business value driven.  You do the things that have the biggest impact, the useful things, the things that people need and which give us an edge or push our service levels and capabilities out a little further.  And lets face it, these are the things that only people immersed in the organisation tend to be able to do (if only they had the time to do them).

Even at UNE where we are fortunate to have a relatively recent and therefore still quite clean warehouse and BI implementation we have to do maintenance and housekeeping which simply has no direct business benefit.  When you only have a team of 3 tasked with providing intelligence to the entire institution, you don’t have a lot of time for upgrades.

I’m therefore intrigued by things like Google Apps which claim (amongst other things) to help free up IT resource by handling the more mundane aspects of our lives, and note with interest the pace at which Google seems to be swallowing up the education market across the globe.  Their latest website shows a map which claims Australia has between 250K and 3 million education users and over 5 million worldwide.  I know that Adelaide, and Macquarie universities use Google Apps as do Waikato and Auckland in New Zealand and recently they were joined by the NSW Department of Education.  Just four days ago, Dublin University rolled out email to all its students, ad-free with 7GB of storage.

google-apps-map

Google have also just launched the Google Apps Education Community Site and the Google Apps Education Resource Center.

If you use Google Apps, what is it like?  As a member of staff or a student?  As an IT person? Does it help, does it make life easier and does it free up some of your time? Does it even save you money as Google claim it will?

Initially I think my view of this type of ASP model was a sceptical one, I probably thought of it as the thin end of the outsourcing wedge, or just another large corporate trying to get easy revenue from the education sector.  But I think differently now, I think that anything that allows us to focus on what we need to be doing and what our institutions want us to be doing has to be good - because then we are delivering business value.

2 comments »

Posted in Australia, Education, Google, Scrum

Applying Scrum to BI/DW Part 2

June 9th, 2009

Given the feedback on the original article, I thought it worthwhile to post an update which includes some new ideas and approaches gained from our own team and from those who have commented and emailed me as a result of that original post.

une-scrum

So, before I jump into the questions, here are some variations that we have successfully trialled and adopted in our own team very recently.

They follow some really good, constructive sprint retrospectives in which we identified that we were a bit too inwardly focussed.  Retrospectives really are a golden opportunity to identify and try new things if you are prepared to recognise them.

Have your daily stand-ups on customer turf

Literally.  You need to ask permission obviously, but I doubt they’ll refuse.  This act symbolises your committment to the project, the associated business processes and all the non-IT aspects of what you’re doing.  You will have access to people who wouldn’t ordinarily come along to your daily meetings and you might well have a few of them dropping by just to see what its all about.  You’ll find out things you couldn’t have known and which could save your hours or days.  Plus, its fun, you get to talk to the real people and build real relationships with them.  Scary huh?

Email your stakeholders with a summary of each retrospective

We do a ‘What Went Well’, ‘What Didn’t Go Well’ and a ‘What We Will Do Differently Next Time’ whiteboard summary after each sprint.  A snappy bulleted version goes to our executives and interested stakeholders.  Sometimes it is ugly reading but we preface it with a statement about how we do this in the interests of identifying process improvements and striving to deliver to their goals as effectively as possible.  No one can argue with that and we have only had positive feedback on this approach so far.

Rotate the Scrum Master Role

Obviously this hinges on having sufficient people in your team who can and will take on the role but it is just that, a role.  It has nothing to do with management or seniority.  There might be a few raised eyebrows outside your immediate team, but generally they will be from people not used to letting go of the reins so a little education and communication here will go a long way.  With a team like ours where we just can’t afford the luxury of a full-time dedicated Scrum Master, this works really well.  It also helps in the shared understanding of what we are expecting of each other and this in turn can only benefit the team.

To follow up on the comment posts…

Could we use this approach (Scrum) as a consultant?

Absolutely!  I can’t think of anything more compelling than a consultant who gives me an option to call a halt, change the scope or rejig the priorities at the drop of a hat.   If I were still consulting I would definitely be offering this in the shopping list of options.  It takes a little education again and I suspect the burndown chart will need a little introduction if it is to replace the Gantt chart but that is well worth investing some time in.  Abdel points out that without a plan this might be a harder sell, but you can still have a plan, indeed you might invest a half sprint or mini-sprint in developing the initial backlog to give your customer some comfort in the approach.

Is there cross-skilling or do people tend to stick to their traditional roles?

Again, due to the size of our team we all pretty do whatever we can and the breadth of our abilities widens each day.  We are generalists, we do a lot and we realise we probably don’t do what we do at the precison level of a specialist but we have a lot of combined IT experience in our team and work in an environment where learning is actively encouraged and supported.  That also makes life more interesting, keeps our skills up to date and ever-growing and, to be frank, makes us more employable.

No comments »

Posted in Agile, Scrum

Applying Scrum to BI/DW Part1

June 1st, 2009

This post is inspired by Abdel’s comment here in which he asks for some specifics about how we actually apply Scrum in a BI/DW environment. I’ll answer the questions directly and add a few bits and pieces as they come to me. Of course this is just one perspective and as with most things in life, we’re learning as we go but I am more convinced than ever that Agile is the way to go for BI/DW development.

How do you specify teams?

We have little option here. There are 3 of us in our BI/DW team so we are always involved. We’re doing a lot of work with the Planning department at the moment so they are also in the team most of the time. There are of course times when we need to pull in a boutique developer - someone who has a special skill or expertise we need for a specific purpose - so they become part of the team for perhaps just one or two sprints.

The biggest hurdle we’ve had to overcome is identifying and getting a product owner, someone who not only has the vision but can also make decisions. These people are in high demand and are few and far between in most organisations. If they do their job properly they also need to do a lot of running around and consulting in order to make sure what we’re working on is indeed what we should be working on. We’ve found one now, I just hope we can hang onto them.

How do you choose the sprint process or sub-process?

This is where the product owner comes in although generally in practice we just know what it is we are supposed to be working on. We still have some kind of governance structure in place and I imagine you do too. There will be someone saying ‘you need to get x, y and z delivered’. On this basis you can say we’ll work on x for 2 months and then review what has been achieved. In that 2 months you might do 7 sprints and each one will chip away at the backlog of requirements until either your product owner says they have enough or you have some other higher priority to focus on.

When is it ok to stop your datamart development and move on?

I definitely think it is better and easier to focus on a delivery area for a period of time rather than saying you will deliver a product in its entirety - you’re getting into dangerous territory if you do the latter as you can’t accurately estimate when that will be and as we know, the scope and priority of the product delivery components will change constantly from day one. You specifically asked about delivering a datamart - you might for example, choose to deliver a single fact table with maybe 6 key dimensions. You might have other stories on your backlog that you might not get to. These could be things like:

  • deliver an aggregated fact table or some kind of high-performance summary table
  • migrate historical data into the core fact table
  • add new attributes to some of the core dimensions
  • add new dimensions to the model

This is where priorities and time come into your equation. If you can, you may keep delivering all of the above, or you may stop and put your energies into something entirely different. The approach manages whatever is needed for your organisation. The main thing is to ensure you deliver something of value in each sprint. Dimensional models are by design very extensible so this again lends itself very well to the above.

Sprint Duration

We’ve moved to 10 business day sprints, that works much better for us. A month is just too long and we run out of steam after the second week. With a demo day, we’re now not starting sprints on the same day of the week each time but that seems to be working out ok. Keep the flexibility to try new things, I think that is the most important point here.

Daily Stand-Up Location

In an attempt to improve collaboration we are having our daily stand-ups in the business area that we are doing the development for. Although this is a little bit inconvenient for us, it seems to help, we are working with them on their terms and often it is the best way for them to see and hear what we are doing. It also means they can easily get involved in our daily meetings and I think sends the right signals.

6 comments »

Posted in Agile, Business Intelligence, Data Warehousing, Scrum

Tipping the Scales away from Project Management

April 29th, 2009

Judging by the number of questions I’m being asked about Scrum at work these days I would say the move toward Agile Software Development at UNE is real and gathering momentum.  This is great news, it means that we have a broadening group to share ideas and approaches with and of course a little team-on-team competition - all very positive and welcome.

img_4599The Web Development Group within UNE ITD’s Application Management Services  is the latest group to be pushing the adoption within their area and this is significant.  It signals the steady recognition of Scrum in the broader university community which means more people will become familiar with what we are doing and of course more people will benefit from the approach.

I’ve already been reminded that our User Stories could do with a little work and judging by our current sprint burndown chart, I think my ScrumMaster skills also qualify for that!

So to Matt, Steve, Gerwood and everyone else involved - Good Luck and lets drive this thing deeper into the software development culture together.

Is anyone else out there actually using Scrum for BI development in a University?

No comments »

Posted in Agile, Scrum