Archive for the ‘Agile’ 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

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

Protracting Peers

April 19th, 2009

protractor

Remember these things from school?

Good for measuring angles, and indeed reminding ourselves that there are always other angles or perspectives on everything we do.

I was browsing a colleagues’ blog last week and found an interesting entry that points to a post in the blog of Ben Collins-Sussman.

The post is about the insecurity of IT ‘nerds’ with respect to their work, specifically the ‘develop in a vacuum‘ mentality and the abhorrence expressed at the idea of peer review.  It was written almost a year ago but people are still adding to the debate today and the point is most definitely still valid, very valid, and not just within the sphere of IT.

Our very own DVC, Professor Graham Webb blogged about academic standards in general terms last week and made the point that peer review has an important role to play here too.  I’m not implying that academics or we IT nerds are more insecure than anyone else, in fact I think it is a human trait that we can all improve on.

You can read Ben’s post in its entirety, complete with the subsquent 90+ comments here, but for me, the closing paragraph says it all.

Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes. You are not your code. Do not be afraid of day-to-day failures — learn from them. (As they say at Google, “don’t run from failure — fail often, fail quickly, and learn.”) Cherish your history, both the successes and mistakes. All of these behaviors are the way to get better at programming. If you don’t follow them, you’re cheating your own personal development.

Of course Agile helps us come out of our boxes a little bit and encourages the team approach to planning and execution and I think with that, the team responsibility for failure and subsequent improvement.  It is probably worth remembering that actually soliciting critique is healthy and (aside from ultimately improving the end result) if you are concerned about shouldering responsibility for everything, it provides another pair of shoulders, free of charge.

No comments »

Posted in Agile, People