agileben

New Blog: agileben.com/blog

2016-04-22T11:26:00.004+10:00

Hi,

As part of setting up a new website I've moved my blog over here:

agileben.com/blog

Hope to see you over there.

Ben

An initial problem with Large Scale Scrum (LeSS)

2015-12-08T15:36:00.001+11:00

I've noticed a bit of a problem with Scrum: it's comes across as hopelessly idealistic and simplistic for many people hearing about it for the first time. If you work in an organisation of any complexity or size you will have felt this gut reaction to hearing a Scrum expert explain the framework: it seems to ignore the reality of the current organisational complexity, existing roles and management thinking.

I was in Sydney last week attending the Certified LeSS Practitioner training by the wonderful Bas Vodde.

At the training I found LeSS triggered an even worse gut reaction: as a direct application of Scrum at organisational scale LeSS seemed too simplistic to address the challenges across multiple teams, systems and functions. The challenges seem much more difficult at organisational scale compared to adopting Scrum at a team level.

I happy to say that after 3 days of stories, exercises, insights and some hilarious videos from Bas, I feel I got past this initial "it's too simple" gut reaction and gained a new perspective on Scrum and some new ways to think about agility at organisational scale. Here is one of the best bits from the training:

Actually creating real feature teams. Feature teams done properly are for me the central idea for organisational agility in LeSS. This includes the restructuring into fully cross-functional feature teams that work across components in the architecture and implementing the related changes to reporting lines, job descriptions and engineering practices.

One of my favourite parts of the training was how Bas positioned feature teams as a way of forcing organisational agility through continuous learning. He suggested we welcome the problems that specialisation brings. Forming feature teams allows us to deliberately set up a conflict between specialisation and prioritisation. You could also see this as a conflict between efficiency and agility.

If a Scrum team's purpose is to always work on implementing the highest value customer features then there is often going to be a significant imbalance between skills and features. The current specialisations and systems knowledge available in a given team will often not be suitable to implement the selected highest value customer feature.

Bas suggested we exploit this imbalance by challenging teams to learn new systems, skills and domain knowledge and to use this imbalance to force this learning. On the other hand, when there is an available team that already has the skills to implement a feature we should take maximum advantage of the skills in that team by implementing that feature in the best team possible.

This idea of treating team members as expert learners, not as expert specialists was repeated throughout the training and was a challenging idea with many ramifications.

"I used to be a BA, but now I'm a team member"

Many of us had fears about the willingness of staff to be proactive learners and their willingness to work outside their specialisation. One helpful topic was a review of McGregor's Theory X and Theory Y management beliefs, and a reminder that these beliefs can be diabolically self-reinforcing: if you believe staff need a clearly defined job role to be effective this will create narrow work behaviours in staff. Bas pointed out shifting management beliefs takes lots of time, and probably lots of beer.

There were a lot of other gems coming out of the LeSS training, and I'll save these for a future post: scaling the Product Owner role, the feature team adoption map, differences from SAFe and new perspectives on team level Scrum.

If you are interested in scaling your agile adoption outside a single team feel free to get in touch, I'm happy to give an overview of LeSS or discuss how LeSS might be useful in your context.

Is aiming for "done" within a sprint harmful?

2015-10-15T18:07:00.000+11:00

Many of my clients new to Scrum often try to fit everything into a 2 week cycle but find that all the work required doesn't fit! Often the definition of done is too long to get something to "done":

One response to this problem is to blame a lack of upfront analysis, and suggest it would be easier to commit to getting to done if more analysis was done up front, and while we are doing that perhaps testing could be allowed to spill into the following sprint:

Unfortunately this suggestion, to do analysis one sprint ahead and testing one sprint behind, leads to long end to end lead times (six weeks in the above example); It also reduces our planning agility, giving us only one chance to implement and provides limited opportunities to react to feedback or to learn as we go.

At this point I usually advise teams to start by looking at making the stories smaller by splitting stories up so that all activities do fit in the sprint. For new teams this can be difficult especially if we have not done any analysis to meaningfully split the story and does not really address the "one chance to get it right" problem.

Consider splitting the work into three iterations: one to learn, one to get it working, and one to polish for release, with all team roles and activities inculding development, testing and review happening for each iteration. At each point collecting feedback and refining the plan:

The first iteration of the story (v1 above) could start from nothing: analyst, developer and tester could working together through the sprint to discover what is possible, what is useful and how we might build, test and deliver it. I'd suggest the team aim to demonstrate some working software at this stage, even if only a prototype of part of the story. In v2 we might aim for a fully implemented and tested version perhaps with some rough edges, and in v3 we might aim for a fully production ready operational version. In this way we are deliberately not getting the story to "done" each sprint, instead emphasising learning and iteration over completeness.

Based on this chain of thinking I would say too much emphasis on getting to "done" (or getting it "right") can get in the way of our ability to learn iteratively and isn't learning fast the reason we are using Scrum in the first place? I'm suggesting that creating multi iteration stories could be a useful practice in this context. If all else fails you can always increase your sprint length: a 3 or 4 week cycle is still much better than 6 weeks!

This is an early draft post, feedback welcome.

Help us crowd-fund an amazing Lean Kanban conference in Melbourne this September 2013

2013-05-06T21:53:00.002+10:00

I'm really excited to announce the Lean Kanban Australia/New Zealand conference 12-13th September this year! We're using a crowd-funding campaign to validate the concept in a lean way :-)

Checkout http://www.pozible.com/lkanz and pledge to buy a discounted ticket. There are only 40 discount tickets available so get in fast to secure a really cheap price and to show your good taste, and your support for the conference.

Also, talk to your company about the opportunity to sponsor the conference, they can sponsor direct from the pozible campaign or contact any of the organisers.

Finally, please put the word out via twitter or your own blog. Help us bring the world's best Lean and Kanban speakers to Australia. Let me know if you have any questions!

Ben

A new kind of limited WIP: Card duration limits

2013-01-22T15:18:00.000+11:00

Here are my notes from my "99 second presentation" from the Limited WIP Society Melbourne meetup today:

Today I want to talk about another kind of limited WIP: a card duration limit, or if you will a dynamic batch size limit:

I'd like to propose that we could make more use of duration limits on our software development processes, basically by pulling a card out of our Kanban process if it exceed a pre-determined system duration limit and putting it back into the backlog, probably with an indicator that it had used up the allowed capacity.

We would then have an opportunity to re-prioritise the task based on knowing it has hit the limit and if appropriate re-queue the task. A bit like an operating systems does, it would prevent one task from consuming excessive system capacity and by freeing up system capacity we allow other, possibly higher value cards to flow through our process.

I would imagine this might allow us to control the upper cycle time of our system, preventing late and surprising high lead times. Instead of having to wait for cycle time to be measured to indicate we had a problem, this duration limit would act as a leading indicator for early intervention while the card was still in process.

One consideration to balance would be the costs of re-work and task switching when we decided to re-start that task at a later time.

However, having this duration limit would allow us to safely take on very risky, unknown size and unknown complexity cards while limiting the effect on flow. I wonder if this would then allow us to more safely exploit the variation in tasks sizes in software development for maximum economic return.

So I propose we experiment with limiting card durations and observe the economic tradeoffs that result, I'd be interested in hearing your thoughts.

PS. You can probably tell I've been reading Don Reinertsen recently.

PPS. I'm running an Introduction to Kanban 2-day course in Melbourne.

Startup Weekend Amsterdam

2012-07-07T22:38:00.001+10:00

So I'm at Startup Weekend in Amsterdam, learning about customer validation and lean startups. It's a pretty crazy environment, lots of energy and even a famous speaker to get us started:

Steve Blank makes a surprise appearance at #swams

After the pitches I joined a startup that helps researchers find foreign correspondents in hard to research countries. The're doing some interesting things around quickly geolocating potential corespondents.

Right now my team are looking to talk to anyone who does foreign research e.g financial analysts, journalists, academics or perhaps an internationally expanding business. If you or anyone you know does this kind of thing drop me a line via email (ben at agileben.com) or twitter @agileben.

Wish us luck, I'll let you know how it goes in this or future posts.

Your first day in Appsterdam

2012-06-28T23:11:00.000+10:00

So you've been inspired to visit Appsterdam, perhaps like me you heard Mike give a talk at a conference and have found yourself planning a trip to Appsterdam. What's next? How do I get around? Where is everything? What do I need to do to survive my first few days in Amsterdam?

Here are some tips for those arriving in Appsterdam.

Before you arrive

Get involved in the meetup group

First things first, join the Appsterdam Meetup group and introduce yourself. Check the dates for the regular sessions (weekly lunchtime lectures and weekly evening drinks every Wednesday) and look for upcoming guru sessions and speakers club meetings. RSVP well in advance for these as they fill up fast.

Consider timing your arrival so you can get yourself sorted (see below) and then meet everyone on the Wed lunchtime lectures and/or Wed evening social meet up.

Follow some Appsterdamers on Twitter

Add some of the @appsterdamrs (Official Twitter Account) to you twitter such as @bmf (Mike Lee) Mayor of Appsterdam, @pauldarcey (Paul Darcey) CEO of Appsterdam, @judykitteh (Judy Chen) Chief Community Officer, @spllr (Klaas Speller) COO of Appsterdam and the many others using the #Appsterdam hashtag.

Learn at least a few words of Dutch

Knowing the local language is not 100% necessary because the Dutch speak excellent english but any effort you put in will help you feel more comfortable here. I've had some luck with the Pimsleur digital dutch lessons. I downloaded them to my iPhone and listened to them for 30 mins each day for the month before I visited. I wished I had started earlier as I only made it to lesson 8 of the 30 in that time.

Book some Accommodation

Accommodation in Amsterdam is expensive and generally a little difficult to arrange. I had a lot of success with the AirBNB service. You should get someone in your social network to provide a reference on airbnb if you can. A similar but sometimes less expensive accommodation booking service is run locally by Frederic Rent a Bike.

For short term stays try Eden Rembrandt Hotel. For longer term accommodation you'll need to brave the fragmented and chaotic real estate market. Try the following agents as a first point of call: Barney at Housing Rentals and Martijn Schneider at Housing Agent.

Download the essential apps

You’ll probably not have a data plan on your phone when you arrive, so until you obtain a sim card (see the section later on how to get one) you’ll probably find an offline map useful for getting around. I use the CityMaps2Go app for my iPhone in Amsterdam, as the open source map data for Amsterdam is excellent, has offline search, shows your compass heading, and has bookmarks.

For public transport info (trams, trains, busses, ferrys) you can’t go past the 9292ov Pro app. It works in english, has search, planning and maps. As an online alternative, Google Transit is excellent in the Netherlands.

For finding places to eat or drink Foursquare has been pretty useful. You can use the lists of favorite places from other users to discover Amsterdam.

Getting yourself sorted on your first day here

Navigating the Airport

The airport is huge. Be prepared for a long walk from your arrival gate and pass through immigration. Once you have your luggage don't forget to use your credit card to get some local currency (euros) from the ATM machines. You'll use this currency in the next step.

You'll want to catch the train to get from the airport to the city, Central Amsterdam, it's cheap, fast and frequent.

Get a chipcaart for use on public transport

Find the train station and line up at the big ticket counter so you can acquire your amazing OV-chipkaart. This is a touch-on / touch-off card similar to London's oyster card or a working version of Melbourne's myki card with the bonus of working everywhere in the Netherlands and on all form of transport including busses, ferries, metro, tram and train. The card itself costs € 7.50 and you will need to put at least € 20 on the card to be allowed to use it on trains.

Platform 1 has the trains to the city. On the platform walk along until you find the chipcaart reader and check in (touch the card to the reader). Board any train going to Amsterdam CS (central station) other than the "freya" as this train requires a special ticket.

At central station you will need to check out (touch the card to the reader again) at the exit of the station rather than on the platform. Try not to forget to check out otherwise you will be charged additional fees on your card.

Find a tram to your accommodation

The trams are fast and frequent and only surpassed by using a bike to get around (see later for how to acquire a bike). Your accommodation host will typically tell you what trams you can catch to your place. Have a look at the official simplified tram map to see how the trams work.

Get a sim card with data

Being offline is a real problem. After a little research I settled on T-Mobile’s pre-paid sim card with a 1GB data bundle. It’s a small fee for the sim card and you add € 14.95 for the internet. Ask the friendly staff at the store to activate your internet for you in the store, and to change the telephone system default language to english.

Use your offline map to find a T-Mobile store, here is an online map of the T-Mobile stores. I went to the small city store at Nieuwendijk 200 near the corner of Gravenstraat. You can save this address as a pin / bookmark so you can find it offline.

Visit Appsterdam Centraal

Now you are online and can find your way about, get yourself to the Appsterdam Centraal HQ located in the co-working space called BounceSpace. The address is Weteringschans 28. Here you can hang out, use the wifi and meet some appsterdamers.

Getting a Bike

And finally, to become a true appsterdamer you need a bike. Grab an appsterdamer from the HQ and head out to a market. I went to the second hand bike place at Waterlooplein Flea Market. Take a bike for a test drive, make sure they adjust the height of the seat to suit you. Make sure they add on the front and back lights, at least one ‘better quality’ lock (locals use two locks) and a bell. Negotiate a price for the whole lot (not each individual part). Expect to pay between €80 and €100.

Update 11th July: Accommodation and bike rental tips thanks to Judy.

Agile Australia 2012

2012-06-05T14:14:00.000+10:00

I had a surprisingly good time at Agile Australia last Thursday, well done to the programme committee. I was only there for part of the day on the second day, but the quality of the talks I attended were much higher than previous years.

The standout talk was of course James Ross with his interesting, educational and laugh-out-loud funny talk "Why nothing you ever do might make the slightest difference: A crash course in the Theory of Constraints"

Also fantastic to see was Nicholas Thorpe and Fiona Siseman's "Agile Board Hacks" a tour de force of real word agile boards based on their excellent blog here: http://agileboardhacks.com/

Another talk I really enjoyed was Design Eye for the Dev Guy by Julian Boot with a bunch of tips around basic design principles such as proximity, enclosure, continuity and connection.

Finally I'm hanging out to see a health dashboard tool based on James Brett and Marina Chiovetti's wonderful talk "Continuous Risk Management".

I hope the slides for the above talks will be available, I'll link to them here when I find them.

My thoughts after 18 months using AWS EC2

2012-06-04T15:57:00.001+10:00

Over the last 18 months I've had the opportunity to get intimate with Amazon's cloud service: AWS EC2. It's been a great experience and I wanted to share some highlights.

For the first time in my career I've been embedded in a operations team, and have experienced first-hand the difficulties involved in provisioning, monitoring and configuring infrastructure. To say that AWS EC2 is easier than physical infrastructure is a whopper of an understatement. As a developer I had no idea how hard it is to get a production scale server provisioned.

It's been an eye opener to realise that when I say "just setup a test server for me" I really mean purchase the equipment including blade, chassis, memory, cables, disks then deal with external ISPs, Data Centre staff, assign rack space, power, cooling, network interfaces, IP addresses, DNS entries, configure the storage hardware, load balancers, backups, alerting, performance monitoring, users, permissions and logging. All this takes months.

Thanks to EC2, today I think nothing of having hundreds of servers created for our developers and testers every day, at a whim and entirely self-service. It takes us minutes to provision complete test environments in EC2 containing dozens of servers.

Ok, so having a cloud is obviously handy, and not that exciting once you get used to this capability. What makes AWS particularly impressive to me is two things: customer service and innovation.

I've found working with Amazon a pleasure. I have access to online support ticketing, immediate phone contact and personal service from a local sales manager and a technical architect.

As one of the biggest users of EC2 in Australia we probably get pretty special attention. We even had the CTO Werner Vogels visit our office and talk to us (more on this in a later post). Having said this, I like to think I could access this level of service as an independent business if needed.

When we've had issues with AWS I've had all but one issue resolved quickly. The one issue that has taken a while to resolve happens to less than 1% our instances, and may turn out to be related to the way we use the API. I'm a very happy vendor manager.

Beyond fantastic customer service, I've been really impressed with the speed of innovation as evidenced by the number of new or improved services released just over the time period of our project. Since we started AWS have almost halved our costs by introducing small and medium 64bit instances. In the same time period we've gained multiple VPN links to our VPC allowing our China team to connect to our test environments in the same way as our Melbourne team. We've also been able to adopt the new IAM user management tools and start using the new official Ruby SDK in our automation tools.

Attending the AWS Summit last week in Melbourne opened my eyes to the sheer number if services that are now available. I'm looking forward to trying out Spot Instances, Cloud Front, Dynamo DB and more.

If you liked this post please subscribe to the blog and get in touch on twitter.

Leaving on a jet plane.. here I come Appsterdam

2012-06-01T11:44:00.000+10:00

In about one week I'm finishing up my current gig and heading out in to the wide world. First stop.. Appsterdam!

Inspired by Mike Lee's talk at YOW, driven away by the awful Melbourne winter and encouraged by friends and family visiting Europe at the same time, it was an easy decision to go check it out.

I'm hoping to spend time reading, learning, catching up with interesting people and generally looking for the next opportunity.

In particular I'm interested in trying the lean startup approach. I'm hoping my experience with agile, lean, kanban and cloud will mix together with mobile and ux into something great. Stay tuned to this blog (subscribe to the rss) and get in touch on twitter.

Looking back on 18 months at REA

2012-05-24T15:35:00.000+10:00

I've just finished an 18 month stint at realestate.com.au in Melbourne a couple of weeks ago. It's been a fantastic gig and a remarkable place to work. I wanted to share some of the things I've found particularly interesting in a series of blog posts.

REA is an amazing place to work, if I step back I can see I take for granted a level of sophistication in technology, process and staff that most companies in the world will never attain.

For example, one of the biggest problems I had managing teams here is that there are too many highly experienced and talented staff! Yep, that's been a real problem for me. It's not a problem I mind having, but it does make design decisions a lot harder to make.

On a process front, Agile and Scrum are yesterday's news, instead most teams here are moving beyond these ideas to newer and broader sources of inspiration such as Lean, Kanban, Lean Startup and Agile UX. It's exciting to be part of a team that is constantly adapting and improving.

It's also been one of the only places I've seen distributed agile applied successfully. The investment in communications technology (e.g always on Skype) and frequent travel between sites have been impressive and very forward thinking.

All this is the backdrop to the project I've been working on: code named 'Gandalf' we've been making huge inroads into adopting continuous delivery practices. Using a combination of existing and home grown tools we have moved beyond simple continuous integration to fully automated building, testing, packaging and deployment in multiple environments including Amazon EC2 and VM Ware.

A dog dressed as two pirates carrying a chest

When I look back I am really proud of what the team has achieved:

Providing on-demand end-to-end testing environments for developers and testers in multiple teams
Learning, adopting and adapting Amazon's EC2 cloud
Working through challenging DevOps issues such as security, monitoring & availability
Creating our own tools to automate our integration with EC2, VM Ware, NetScaler and Nagios.
Building a fully automated end-to-end testing pipeline and solving artefact version management in the process
Using metrics to drive improvements to our environments
Creating a consistent operating system platform in all environments (EC2 and VM Ware) built using an "infrastructure as code" approach
Creating services that let us eliminate environment specific configuration inside our application packages

Each of these successes was won through plenty of mistakes and challenges. I hope to share some of the lessons I've learned in future posts.

Stay tuned and don't forget to add my new blog to your reading list.