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
Friday, April 22, 2016
Tuesday, December 8, 2015
An initial problem with Large Scale Scrum (LeSS)
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.
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.
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.
Thursday, October 15, 2015
Is aiming for "done" within a sprint harmful?
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.
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.
Monday, May 6, 2013
Help us crowd-fund an amazing Lean Kanban conference in Melbourne this September 2013
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
Tuesday, January 22, 2013
A new kind of limited WIP: Card duration limits
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.
Saturday, July 7, 2012
Startup Weekend Amsterdam
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:
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.
 |
| Steve Blank makes a surprise appearance at #swams |
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.
Thursday, June 28, 2012
Your first day in Appsterdam
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.
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.
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.
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.
You'll want to catch the train to get from the airport to the city, Central Amsterdam, it's cheap, fast and frequent.
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.
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.
Update 11th July: Accommodation and bike rental tips thanks to Judy.
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.
Subscribe to:
Posts (Atom)