Craig Brown

Based in Melbourne. Works across SE Asia.

P: +61412406414

E: craig.brown@craigwbrown.net

T: @Brown_note

Evaluator
Better Projects Blog
@Brown_Note
Presentation decks
Events - Melbourne Scrum User Group
Events - Agile Business Analysts, Melbourne
LinkedIn
Tabar blog - Agility - Innovation - Training - Consulting
Contact

Contact

Loading,

% complete

Evaluator

Evaluator
- My business is called Evaluator.com.au. Not only do we evaluate your performance against a range of business and technology standards, we can help you grow and improve.
  
  Come and take a look at the details.
  
  Even though I am based in Melbourne we can help you anywhere in the world.
Posts

Posts

Profile
- Agile will never work here
  
  Sep 14, 16
  TL/DR: Agile will never work in Asia, America, Argentina Australia, China, India, or anywhere, really.
  
  Scrum does not work in Asia.
  Why not?
  
  A hierarchy culture where people do what they are told by their boss
  People value harmony over disruption and so disupting the way things are is frowned upon
  There is a deeply rooted deference to authority and conformity
  Most of the work is based in the outsourcing industry and has a cost focus. Quality, innovation and agility are not valued.
  
  5 reasons why agile won't work in Germany
  Why not?
  Deference to heirarchy is a very strong aspect to the national culture
  The whole society is structured into silos. Focus on your job and do it well, rather thank think about the broader picture
  Germans love planning, and so let's focus on planning.
  Germans love perfection. Iterating on an imperfect implementation drives us nuts.
  We have a conservative culture and don't want to rock the boat.
  Why Agile won't work in Argentina
  Why not?
  Entreprenuers and managers make decicions based in short term horizons
  Becasue we only care about the immediate future, the cost of quality feels to high
  We have a service industry (like Asia) and so project cost is more important than longer term sustainability
  Our culture celebrates heroes, so we value individual contributions over team culture
  Heroes get rewarded. Also, our pride and ego put our individual identity ahead of our team
  There are more. And not just regions, but industries also. I bet we can find posts on why Agile doesn't work in banks, startups, R&D projects, government, etc.
  
  I'd love you guys to post links to the comments and help expand this list.
  
  Is there an antidote to these problems? Maybe
- “Cognitive bias cheat sheet” @buster
  
  Sep 05, 16
  
  The now famous List of Cognitive Biases on Wikipedia is now getting ugly and cluttered.
  
  Fortunately this guy has written a better description and organising of the biases. He frames the long list of duplicated and marginally specific biases by the problems they solve. Of course this description is subject to a framing bias, but it does seem to work as a sense making model.
  
  Do take a look.
  
  “Cognitive bias cheat sheet” @buster https://betterhumans.coach.me/cognitive-bias-cheat-sheet-55a472476b18
- Book Review: The Heretic’s Guide to Management
  
  Sep 04, 16
  
  The Heretic's Guide To Management: The Art of Harnessing Ambiguity by Paul Culmsee
  My rating: 5 of 5 stars
  
  TL/DR - It’s a great, entertaining book on managing people in a complex world. Buy it and read it today.
  
  I am really happy Paul and Kailash wrote a follow up to their 2011 book The Heretic's’ Guide to Best Practices. That was a book with great storytelling weaving together 50 years of management academia.
  
  It told the story of how work is inherently complex and you can’t just treat it like a game with a simple rule book. They showed how and why the simplistic approach to work of best practices is antithetical to actually doing good work together.
  
  I read that Heretic’s guide enjoying the book as a bringing together and sorting of a bunch of ideas I was already familiar with. They created a great reference book showing the history of good and bad management ideas that I could point people at. It encapsulated for me years of learning that I had acquired through research, conservation and study. Now it was much easier to get people to read the book and they could catch up in hours or days.
  
  Amusingly, at the end of the Best Practices book they broke the promise of the title in a way typical of both their larrikin senses of humour. They shared a best practice with us for dealing with complex social systems. (I won’t share it here. Read the book.)
  
  This new book is also a good read. It’s full of humour and anecdotes, but is backed with an oblique and deep academic pedigree. Kailash and Paul know how to look beyond the business bestseller list when they research. They follow the academics and they check the academic theory against their own extensive experiences. This adds up to a well researched and entertaining story that you know you can work with.
  
  Once again this book kicks off with a sharp and pointed criticism of best practices, this time in the guise of management models. They show how you can quickly establish your own management framework in four easy steps. This is done tongue firmly in cheek to arouse your natural skepticism about snake-oil dealers peddling certification schemes.
  
  (As if YOU would be suckered, dear reader. You’re one of the smart ones.)
  
  Having you in on the joke, they then proceed to take you on a tour of how our brains manipulate us when we aren’t expecting it; name-checking lists of cognitive biases, provoking us with statements designed to generate an emotional response in you to what they write, until eventually settling down and getting to the heart of this book's idea.
  
  The big idea of this book is about how we deal with uncertainty and the middle section spends quite a bit of time addressing how you and I handle ambiguity. It's compelling stuff and it resonates.
  
  But so what? Is this just another book about complexity? Interesting but of what practical value? Kailash and Paul are all about the pay-off. The author's solution is to recommend we managers use ambiguity to our advantage, even if we don’t always embrace it with love in our hearts.
  
  The last part of the book then follows the precedent of it’s predecessor and ironically provides us with a management supermodel that provides tools for managing (manipulating) people at work by amplifying or diminishing ambiguity.
  
  Once again, the book is an excellent read. It is more engaging and fun to read than many other business books. Both the authors have a perverse sense of humour. Both are deeply skeptical of the fads of the management consulting industry and both are great storytellers. As with the first book I now have a concise repository of a number of important and useful ideas that I can refer people to.
  
  In fact, I like this book better than the first (and I liked the first a lot.) This one is shorter, more to the point, and funnier.
  
  When I read this book I instantly wanted to get a handful of my friends and colleagues to go buy it, and I have bought a couple of copies for people. I highly recommend you go buy it and read it also.
  
  Now.
  
  View all my reviews
- I deeply deeply care, but frankly...
  
  Jul 12, 16
  
  I've been running this meetup group for over five years. I organise content, speakers and venues. People get fed a steady diet of instructive experiences that help them grow as professionals.
  
  But sometimes I get busy and sometimes I can't pull it together. For two years I have run a series of activities designed to attract and install a backup collection of people (alternatives to me) in this meetup community. And I have failed to build redundancy to my key man role.
  
  Some people would find that rewarding; that they are important to the continued existence of a community. Me? I find it annoying.
  
  I am not that special. Anyone could do what I do. It is not technically hard. All it requires is caring about others. And a small bit of admin time.
  
  And so this community degrades because others fail to step in to the awaiting leadership roles.
  
  Fuck you people. Lift your goddamm game.
  
  No wonder workplaces are so full of mediocrity. It's you guys being mediocre.
- 5 Reasons Why Projects are an Essential Tool for Better Business
  
  Jun 26, 16
  Click this image to get a PDF booklet on
  the argument for #NoProjects
  This article is an inoculation against the #NoProjects meme.
  
  Projects are great. Despite the cry on the web about projects being bad for business they can really help you do a better job of organizing your work.
  
  I am writing this as a counter to a meme about why projects are evil and need to be abolished. What was once a sentiment is now a movement (with it's own hashtag, so it really is legit.)
  
  The main arguments against projects seem to be;
  
  Projects are temporary organisations. People that work on projects don't have to live with the consequences of the work they do, and so will eagerly take quality shortcuts that someone else is going to have to pay for
  Projects are organised around impossible goals. Some executive somewhere wants a new product out to market, or internal process fixed and all the big decisions about time money and scope are done before you arrive.
  There are more, but they are essentially minor next to these two complaints.
  
  So, drumroll please.
  
  Read more »
- A note on the 5th LAST conference (that you should go to)
  
  Jun 15, 16
  LAST Conference is in it's 5th year and we happen to be the largest Agile Conference in Australia. We have about 150 speakers and about 160 sessions over two days. We do all this for the price of a fancy lunch. Which is relevant because we provide three meals and a bar tab at the end of the day.
  Get your tickets here.
  See the program here.
  
  Over the years Ed and I have run LAST Conference as a conference we would want to go to. It's a little bit chaotic, it's fun, it's overstuffed with ideas. This year we have tried a few variations on what we have done before. Here they are for posterity and with some comments on how we are going;
  There is a tech conference woven in among the Lean-Agile stuff
  Code retreat is embedded in the bigger conference
  We have expanded the team who program the content
  LAST is over 2 days this year
  Let me elaborate on these;
  
  The hidden tech conference
  To see the tech talks you can browse the program by topic. I have also added a LAST|Tech Twitter handle to several of the specifically tech talks. See here for the list of tech sessions.
  
  Each year I look for something beyond the 'agile mainstream,' because, basically I want some content that I will be stimulated by and most of the agile stuff, well, I want something more. And I suspect a bunch of other people do also.
  
  This year I focused my attentions on a stronger technical program. We have always had tech talks but the audiences for them have been a bit lukewarm. Build it and maybe they'll come.
  
  My motivation here: If LAST doesn't maintain interest from software developers it will eventually fail as a cross-discipline event. If it fails as a cross discipline (aka whole team) event, then it will not be loving up to some of my aspirations for it.
  
  So, borderline tech people, go to the tech talks to help entrench them into the program. Tech people, go along to LAST and enjoy the tech talks.
  
  Code retreat
  I work with Supriya Joshi who is very passionate about the software development community of practice. One of the events she is active in is Code Retreat. I asked her if we could put Code retreat into LAST this year. It's an experiment and we will see how the two fit together.
  
  Code retreat is a place for people to come and get some structured coaching on theor coding skills. It's accessible and friendly.
  
  The expanded team
  Our core team is still Ed, Paul and me. Additionally this year we invited Rajesh Mathur, Ryan McKergow, Kelsey Van Haaster, Victoria Schiffer and Steven Mitchell to help program the content.
  
  Expanding the team expanded the work for me, but the value it brings is important. We get a wider view of what content we should be programming. We broaden our perspective beyond "What Craig reckons." And we increase our network of ideas and experiences.
  
  You can see the results I think. The line-up this year is stronger than ever before. There is diversity in thoughts, ideas and experiences and coherence around values.
  
  2 days of conference goodness
  Our main feedback over the years has been too much content drives people nuts. So we are running the event over two days with a number of sessions repeated on both days. A big thank you to speakers who have donated their time to do this. As a punter coming along, you cna choose to come both days or just one.
  
  This conference is essentially about a community of practice coming together to share ideas and experiences and to learn from each other. Come along and share yours with us.
- Webinar: Project Portfolio Management
  
  Jun 15, 16
  Once I was asked to audit a portfolio of projects in a large IT organization. I asked the project managers, the dev managers, test leads, the business analysts and the business sponsors and stakeholders what they were looking for from their IT projects and how they felt the project was going.
  
  One thing that came from that was a realization that people in different roles have different ideas about what success looks like. And this view shifts people expectations and behaviors. When I had done with the audit I don't know if I found a single project with everyone aligned on the goals, let alone views on how the project was doing.
  
  From that point on I have kept my eyes and ears open to this risk. I have found it to be pervasive in what I'll call "process oriented' companies.
  
  As the years went on I found myself running project portfolios, and setting up portfolio management systems. I ended up with more than one portfolio management book on my bookshelf. I was even sent a PMO book with a note of thanks from the authors for some of the ideas shared on this blog.
  
  I am still in some ways managing project portfolios today, and I remain focused on shared understanding of goals as one of, if not THE most important thing to attend to. This alone is not a trivial task.
  
  Yesterday I was contacted by Isidora from a PMO oriented start-up called ITM Platform and she asked me to promote a webinar they are running. She referenced Kanban in her pitch, which makes it interesting to me. It's on at a time I will not be able to make. Maybe I'll check for a recorded version later. Maybe you can help and drop comments here.
  
  Here is the promotion
  
  FREE WEBINAR with ITM PLATFORM: Set up a Project Portfolio Management Organization.
  ITM Platform has implemented our project management solution in over 300 organizations. And want to share the lessons they have learned with you to help you develop and improve your project-oriented organization.
  What you will see during 45 min?
  
  Design of a project-driven organization.
  Change Management.
  Basic Configuration of ITM Platform.
  
  When? JUNE 16th at 10 am (Boston, Eastern Tine Zone)
  How to register? Click Here: https://attendee.gotowebinar.com/regist…/9108160085963125507
  
  If you register I will perhaps get $1. So I have a big incentive to get you to sign up. What I would prefer is that you guys pass back what you learn in the comments. If you do that I'll donate their payment to a charity that my sister recommends.
- Tips for being a better listener
  
  Jun 01, 16
  
  We all know we should be better listeners. This School of Life video gives 5 specific things we can focus on to improve.
- We are changing LAST Conference this year: Here is how and why.
  
  May 29, 16
  
  TL/DR: We are making changes to LAST Conference to improve the attendee experience. Go check out the sessions you want to go visit on Lanyrd. And then go buy a ticket before they sell out.
  LAST Conference is widely regarded and commented as one of the best industry conferences in the world.
  I heartily endorse this belief. I have been organizing it with my friend Ed Wong since 2011 and we think we have got a pretty good set up going.
  We ask people what they thought of each event a week or so later, and the huge numbers of actual responses, plus the very overwhelmingly positive comments we hear reassure us our initial design ideas were right. We have also been written up by several industry folks unilaterally declaring our event to be amazing.
  We hear that people love the community vibe, the low fuss, non-corporate feel of the event. We hear things like our instructions to "vote with your feet" on sessions empowers people to explore and bail on sessions if they aren't useful or fit for the audience member. And the rich variety of sessions; games, workshops, talks make for a great day. Plus meals and a drinks tab at the local pub that pull people together and provide a place to talk and exchange ideas with co-attendees.
  We have done all this for less than $100 a ticket, because when we originally set this conference up we were looking to help people at not-for-profits, government agencies, small businesses and startups who didn't have the budget to go to expensive training events and conferences.
  Despite all this, we get some complaints.
  The most frequent issue reported to us is that the volume of sessions on one day mean that people get frustrated with the choices they have to make and the opportunity cost of going to one session over another.
  Scarcity equals value, right?
  We have a huge number of speakers and facilitators with lots of concurrent things going on. We charge the equivalent of an expensive lunch for a ticket. So don't we need to make something scarce? We designed the choke point to be the attendee's time. AT first we though that was a good idea - people will just have to come along to the meetups in town, and come back next year for another event.
  This year we are going to try to address the pain.
  We have spread the conference over two days and we have asked a number of speakers to come back and repeat their session from the Thursday on Friday. Not everyone could afford the time, and sometimes we have swapped out speakers but hung onto the same topic.
  We also have (as of the day I publish this blog post) MOST of the sessions published on Lanyrd, which means you can browse through what's on and think about what you want to track and go see. Check out the handy features on the Lanyrd page that help you plan your event.
  So head along, enjoy yourself, and let me and Ed know how you think the conference is doing.
  #EdWongisSexy
- Put your damn photo on your work tool profiles.
  
  May 12, 16
  
  Use a photo on your online profiles at work. Here is why.
  Put your photo on your profiles.
  
  Right now we are more globally dispersed than ever before, and people on opposite sides of the world have had very little interaction or chances to get to know each other. That will change over time, but we’ll also continue to grow and recruit new team members. Managing connected-ness over distance is becoming an increasingly important competence for more and more of our team members.
  
  To increase our ability to collaborate, to work together and be one great team, we need to overcome the impediments that distance puts between us.
  
  Distance presents all sorts of collaboration challenges; time differences, lags in back and forth communication and a variety of other things that slow the transfer of information from person to person.
  
  Distance also stops us from even considering communicating. There is something called the Allen curve, which is backed up by repeated experiments over time that shows that essentially Out of Site equals Out of Mind. If we can’t see you we typically don’t think about you.
  
  Photos on your Slack or Intranet profile won’t make a huge difference to this, but it will help people in other buildings recognise you and know who you are, and think about you as a human being rather than just a faceless name from another place. This combined with other interactions and activities will gently contribute to trust across the geographical divides.
  So put your photo on your Confluence, Slack and other profiles.
  
  Yeah, but no.
  If we do nothing to address trust people will start wondering “What’s he building in there?” There will be suspicion, uncertainty, doubt and ultimately fear. And we all know where that leads us…
  
  So, a photo is a little thing, but it helps. It’s absence hurts.
  
  Tips for a good profile pic.
  
  Here are some tips to do the picture thing well.
  
  Use a photo of yourself. Photos humanize the name from another place. They help people who are travelling recognize you when they walk for the first time into your building. Using a cartoon character, an image from the internet, or a photo of someone else might be amusing, but they don’t contribute to trust, recognition and understanding.
  
  Use a recent image. That picture of me from 2001 isn’t really going to help people recognize me when I walk into their office for the first time next week.
  
  Make it a headshot. Headshots are best - profile photos are small. Don’t make it hard for people to recognise you from the photo.
  
  Make eye contact with the camera. People will be able to look right at you and recognize you when they walk for the first time into your office. Don’t have that photo? Close approximation will probably do.
  
  Smile, Damn it. Look friendly and approachable. Smiling is a smart option. After all, it’s trust we are working on here.
  
  Don’t worry about perfect. Good enough is making a small effort. It shows you care. It shows you have taken a few moments to do something for others. That’s a great step.
  
  Thank you.
  
  Now go upload your profile picture.
- Heart of Agile talk by Alistair Cockburn
  
  Apr 14, 16
  
  We recently had Alistair come to the office and give a talk.
  
  The Heart of Agile is a fresh look at Agile that strips away a lot f the cruft that has built up over recent years. This video is interesting and useful.
  
  It goes for about 50 minutes so find yourself some time and a nice quiet place and sit down and listen.
  
  Here it is...
- Am I doing a good job? Some tips on getting feedback.
  
  Mar 10, 16
  
  Maybe you have a performance review coming up? Maybe you want to work as part of a community of practice to improve your game?
  
  Where do you look for tips and advice?
  
  Blogs with discussions on how a role should be played? These will be useful data points but are based upon someone else's experience. It's valuable. But only so much as asking an experience person who has never stepped into your office and met you team or customers.
  
  Consultants with frameworks that look across organisations? Useful to see what the industry is doing, and you may get some good tips. But following consultant frameworks is a recipe for regression to the mean. It's useful if you are a low performing organisation, but if you are better than average, do you really want to shift your performance towards the middle?
  
  Potentially the best place to get feedback (and many people are going to say 'of course!') is your own local context.
  
  Here is a quick map of some places you could get ideas. All you need to do is make time and go ask a few people how things are going in relation to your work.
- 59 Topics for an Agile meetup
  
  Jan 26, 16
  In case you were running dry on topics...
  
  I scouted the various meetup groups around the world, asked a few people and added some myself.
  Scrum and legacy systems
  Program Portfolio management
  Application Architecture and impact on velocity
  Individuals and Interactions over Process and tools
  User Experience and Scrum
  Business Value – what does it mean to you?
  Handling Tech debt
  Who owns quality, and what do they say about our work?
  Hyper-productivity – breaking the rules
  Scrum in operations/support
  Coaching dojo
  Enterprise architecture – finding the balance of planned and emergent design
  Strategic product ownership
  Managing managers
  Planning poker and other estimation techniques
  Training new scrum teams
  Self organising
  Continuous Integration, Continuous delivery
  Agile Testing
  Acceptance Testing: Just say no (James Shore’s thinking)
  Collective ownership
  Agile tools
  PMI-Agile combo
  Requirements decomposition – epic to story
  Release planning
  Story mapping
  Evidence based Retrospectives
  Innovation Games
  Roadmaps
  Lean Startup and Agile
  Estimating, Velocity, and Charts
  Can Six Sigma help scrum teams?
  TDD
  Definition of Done
  Scrum Certifications & what they mean,
  Failed scrum implementations
  What we can learn from the punks and hippies; lessons from change agents of decades past
  Scrum beyond Development
  Selling Scrum to senior management
  Offshore teams and scrum
  Dan Pink’s Mastery, Autonomy and Purpose
  Hybrid Agile; Friend of foe?
  Management 3.0
  Memetics – why easy ideas are stickier than good ones. What does this mean in the world of scrum?
  Deeper look at the Agile Manifesto
  Open forum with experts
  Complexity theory
  Shu-Ha-Ri-Kokoro
  Heart of Agile
  The Philosophy of Work; what modern philosophy has to say about the way we work
  What is Lean and Kanban
  XP and Scrum combo
  The missing Parts of Scrum
  Agile contracts, Agile proposals
  When to leave scrum behind
  Revisiting scrum roles; There are no project managers, no business analysts, no testers and no developers.
  What Theory of Constraints can teach us
  Startups and Scrum
  Scrum v Kanban/Lean
- Donate to Wikimedia now.
  
  Dec 17, 15
  
  We all owe Wikimedia for the great service they provide in Wikipedia. I donated today, as I do each year.
  
  Your turn.
- A Thin Slice of Value
  
  Mar 05, 16
  
  The very first principle of the Agile Manifesto reads:
  
  “Our highest priority is to satisfy the customer
  through early and continuous delivery
  of valuable software.”
  
  I’m reasonably sure that most people (business, technical and customers) would agree that as a principle this is sound and that we should indeed seek ways to identify and deliver value as early as possible in any development (software or other) initiative. The principle however, only gets us so far, it makes what we want to do clear enough but doesn’t help much with how to actually do it.
  
  This post addresses the howby providing a step-by-step guide to one approach to finding the earliest and best possible slice of deliverable value. The approach is called Blitz Planning and is introduced and covered in detail in Alistair Cockburn’s Crystal Clear [1]. Blitz Planning is applicable in a wide range of contexts, from software development through to business process change.
  
  Re-Introducing Blitz Planning – Setting the scene
  
  Firstly it’s important to understand that Blitz planning is not about generating user stories or identifying epics and features; although it is likely to provide an input to some of these things if used in this context. The output of a Blitz planning activity can inform your release plan however, the key objective of blitz planning is to find the earliest possible point at which business value (revenue or savings) can be delivered.
  
  I like to run this activity as part of an inception, which is the multi-day planning workshop used to kick off a new or re-imagined project, initiative or other piece of work. You can read more about inceptions hereand here. It makes most sense to conduct your Blitz Planning exercise before you start to identify epics or features and while you are still working at a fairly high level.
  
  It’s critical to have all the right people in the room. This means the representatives of all the stakeholder groups who will be impacted by, or who will have an interest in your project. This should include; technical people, business people (including your executive sponsor), process people and if possible your customer (the end user of your product) or their (knowledgeable) representative.
  
  To conduct the exercise you need index cards, stickies, builders tape, sharpies and a large table or floor space. It’s important to be able to easily move the cards around.
  
  Getting Started
  
  Step 1; what are all the things we need to do to deliver this project?
  
  Ask your participants to form affinity groups, by this I mean groups of shared interest, for example you might have, a technical group, made up of developers, QA’s, BA’s and infrastructure/operations folk. Another group may be made up of business representatives, marketing team members and perhaps your project sponsor. If you have end user/customer representatives in the room, they might form a team with training and communications experts.
  
  Ask each team to brainstorm and then write cards for every task which needs to be done. This should include all kinds of tasks, but not processes; for example, "migrate database" or "order hardware", are tasks, whereas "run a showcase", or "run an elaboration workshop" are not. Don’t worry too much about granularity at this point; you will get a chance to review that shortly.
  
  Step 2; where are the dependencies?
  
  Ask each team to group their cards by theme (for example; all the infrastructure tasks form a theme) and lay them out in vertical columns on the table or floor. The tasks should be ordered by dependency in each column, any task which is independent or can be done in parallel with another should be in it’s own column. You will end up with something that looks like this.
  
  Review what you have; at this point, you will likely find some duplicates between the teams; these cards can be stacked on top of one another. You may also identify some tasks that are too large and have multiple dependent parts, break these out until you have only single columns of discreet but related tasks.
  
  Ask each team to review the other teams columns of tasks looking for duplicates, and omissions, merging and refining columns as they work.
  
  Step 3; Creating a big picture
  
  Now bring together all the columns of tasks from the teams, placing them on the table, but leaving a decent amount of space above your cards when viewed from the bottom to top. Align all the columns horizontally in order of any obvious dependencies, for example you may want to take into account any long lead times, such as regulatory approvals or print material runs. Don’t worry too much about these though; they are not critical at this point.
  
  You will now have something that looks a bit like a walking skeleton or story map but is not made up of stories but of all the tasks that need to be done for the project.
  
  Step 4; Estimate and Tag
  
  In this step ask participants with relevant knowledge to tag each card with a high level estimate of how long they think the task will take to complete. These estimates should be given in days, are intended to be very rough and should be based on total elapsed time. These estimates are designed to give the team a general feel for the size of the project, nothing more, so don’t get too prescriptive, err on the side of generosity. Where there are a number of wildly differing estimates on a task, take the opportunity to explore the differences and come up with an agreed best guess.
  
  Tag each card with an indicator of who or which team needs to do it. If a particular person with specific expertise is required mark this on the card too. The objective of this step is to identify key constraints such as a significant amount of work dependent on one individual or team. This should lead to discussion on how this might be avoided and presents an opportunity to think about how you might apply techniques such as the 5 focussing steps from the Theory of Constraints [2], [3]
  
  Step 5; Review dependencies
  
  Now bring your teams together and take some time to review your cards again as a group. Particular cards may trigger ideas for more cards. Question all dependencies, you may find that some things that have been identified as dependencies could in fact be done in parallel. You should also identify and tag any very strict dependencies that exist. An example of a strict dependency might be that you need to develop training materials before you can deliver them.
  
  Step 6 Make magic happen
  
  Now grab your builder’s tape and create a horizontal line above your top row of cards but leaving space at the top of the table. Look at your columns of cards and ask, what tasks do we absolutely need to do to prove this concept. You are looking for the thinnest possible end-to-end slice of functionality. Move these cards above your line to the top of the table. Look for opportunities to make this as fast and a lightweight as possible. Consider options such as not using the end state architecture. Perhaps you decide that you can use a flat file to hold data rather than a database. Make sure you have included any tasks which are not part of the development process, but which need to be done first, such as obtaining software licences, or spiking out a technical challenge. This first cut may not be useable in a production sense, but should prove your concept. This is particularly valuable where your project requires you to integrate several systems.
  
  Place a second line of tape beneath these cards; you should have a gap between the line of tape and the top of your remaining columns of cards. Move cards to make this space if you need to. Now place the cards that are absolutely needed to create a product that someone can use below this second line of tape. This is your MVP; its purpose is to allow you to get early feedback on your product and is an important potential pivot point for the business.
  
  Place a third line of tape beneath your MVP and add the cards that would be needed to create a product that generates the earliest possible business value. This may take the form of earned revenue or savings. This step may trigger discussions about how business value can be measured and may also result in the generation of more cards around identifying appropriate metrics. If this is the case, estimate and tag these cards and place them appropriately.
  
  Now add up the estimates in each column for each of your releases. Then add these horizontally.
  
  At this point, both the team and your sponsor have enormous early visibility over the project, its size scope and complexity. This can lead to a number of important discussions about how valuable a project actually is and how much needs to be included to deliver sufficient value. The team and the sponsor may be either pleasantly or unpleasantly surprised by results but everyone will probably be appreciative of the level of transparency and the shared understanding they now have.
  
  Step 7 Identify further releases and mitigate risks
  
  Assuming that your project sponsor has not decided that the whole project is now a bad idea, you can go on to identify further releases. These can be represented by clusters of functionality that add additional business value, so you may decide to move these up to an earlier release, or you may decide to delay a cluster which does not appear to add sufficient value. You may also spot cards that carry a large amount of risk late in the project, especially if they are tasks that could be very expensive if they go wrong. You can discuss how to mitigate these risks by looking for opportunities to start these as early as possible.
  
  Conclusion
  
  Having used this technique several times now I have found it to be very worthwhile from a number of different perspectives.
  
  ·      It provides you with the high-level planning equivalent of a user story card. (In the same way that a story card is not a requirement but a placeholder for a conversation, the potential releases you have identified are placeholders for further conversation.) You can take each one of these forwards to use as a starting point for more detailed release planning activities.
  
  ·      Both business and technical stakeholders have a shared understanding and level of visibility over the project. This leads to more valuable conversations and the minimisation of the tensions between technology and business that can sometimes emerge, even in the most enlightened organisations.
  
  ·      The approach forces everyone to focus on delivering the most valuable software for the customer as early as possible and on measuring that value.
  
  This post has been my interpretation of how to conduct and use this technique, if you would like to read a more detailed description of its origins and use you should buy and read Crystal Clear or attend an Advanced Agile Master Class where it is taught by it’s inventor, Alistair Cockburn.
  
  References
  [1]      A. Cockburn, Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley, 2008.
  [2]      “Theory of Constraints.” [Online]. Available: http://www.leanproduction.com/theory-of-constraints.html. [Accessed: 24-Oct-2015].
  [3]      M. Naor, E. S. Bernardes, and A. Coman, “Theory of constraints: is it a theory and a good one?,” Int. J. Prod. Res., vol. 51, no. 2, pp. 542–554, Jan. 2013.
- Frameworks for Scaling Agility; A Cautionary Tale
  
  Aug 10, 15
  By Kelsey van Haaster
  
  Note: This post was originally published on LinkedIn
  
  In his seminal paper entitled “Agility from first principles: Reconstructing the concept of Agility in ISD” [1] Kieran Conboy offers the following as a definition of Agility;
  “…the continual readiness of an ISD method to rapidly or inherently create change, proactively or reactively embrace change, and learn from change which contributing to perceived customer value (economy, quality and simplicity) through its collective components and relationships with its environment.”
  Conboy’s definition was created in the context of an evaluation of the efficacy of specific software development practices; it is based on a careful analysis of the terms Agile and Lean and is grounded by research into the history, principles and practices associated with them over the last several decades. Conboy carefully documents the process through which the definition is arrived at, such that it is repeatable independent and trustworthy.
  If you replace the words ISD method, with organisation and scale it to an organisational level it aligns quite nicely with the idea of responding to digital disruption a term used to describe
  “…changes enabled by digital technologies that occur at a pace and magnitude that disrupt established ways of value creation, social interactions, doing business and more generally our thinking.” [2]
  In other words, in order to respond to digital disruption organisations perceive that they need Agility.
  Given the urgent calls for businesses to embrace the concept of digital disruption from organisations such as the Reserve Bank of Australia [3] amongst others; as well as the somewhat dismal figures for the success of technology projects in general [4] it should not be at all surprising that Agile and Lean approaches to doing business are currently of great interest to organisations working with digital technology. This means that more and more businesses are asking how they can use Agility to leverage the perceived benefits of digital disruption within their organisations.
  However, organisations which have attempted to introduce or to scale Agile, have learned that the implications of adopting Agility are far broader than just replicating the approaches and activities that have been successful for individual teams. Adopting Agility at an enterprise level implies a significant cultural and organisational change. This kind of change impacts roles and responsibilities, corporate governance mechanisms, reporting mechanisms, approaches to corporate and financial planning, marketing, sales forecasting and public relations; as well as demanding new and different conversations with stakeholders, shareholders and the user community.
  More than a decade of research into Agility has resulted in a substantial body of literature highlighting these challenges as well as the practical difficulties of scaling Agile in-the-large, which include; managing variability amongst team processes, lifecycles and approaches to developing and managing requirements [5], [6], [7], [8], [9], [10], [11]. Whilst a number of high profile digital organisations have successfully adopted Agile as whole of business approach [12], [13], these success stories are not the majority. So whilst corporate interest continues to grow, so do concerns about the risks and challenges implicit in attempting to initiate such broad corporate change. Consequentially, organisational governance teams are seeking assurances about the potential costs and benefits of making these kinds of changes [14] .
  Enter the Frameworks for Agile in-the-large
  In response to these concerns a number of frameworks offering a pathway to Agile-in-the-large have emerged; some examples of which are DaD (Disciplined Agile Delivery), [15], and more recently, LeSS, (Large Scale Scrum) [16], and SAFe (Scaled Agile Framework)[17].
  LeSS (Large Scale Scrum) championed by author Craig Larman, [15] proposes adding just enough extra structure to the existing Scrum framework to better support scaling to more than one team. LeSS does not add new concepts, rituals or artefacts to Scrum but proposes an approach to applying existing ideas to larger groups with the primary objective of improving communication. LeSS offers a certification scheme and a range of courses targeting both executives and Scrum practitioners and has recently launched a new website which incorporates a similar big picture concept to that proposed by SaFe [16].
  DaD (Disciplined Agile Delivery) [17] is proposed by Scott Ambler, and is an evolution of his work on the EUP (Enterprise Unified Process) [18] which in turn extends the RUP (Rational Unified Process), [19]. DaD proposes a hybrid approach to scaling Agile and incorporates strategies drawn from a range of lightweight methods and Lean principles as well as mandating a set of prerequisite core practices. DaD claims to extend Agile principles across the system lifecycle and provides approaches to managing challenges such as geographically diversified delivery teams, complex organisational structures and multiple technology platforms [20].
  SAFe is the most recent of the Agile in-the-large frameworks and is based on the work of Dean Leffingwell [21]. SAFe proposes a three-tiered approach to scaling Agile, which address the needs of the team, the program and the portfolio. SAFe is the first Agile in-the-large framework to offer a complete package of supporting software, certification schemes, books and training courses driven by an intensive marketing effort [22]. SAFe claims to provide a proven approach to scaling Agile, a claim supported by a number of customer case studies. Software vendors have developed tools designed to support SAFe through both their product and through training and certification.
  SAFe has been the topic of some particularly heated discussions found in the technical literature. These highlight strong concerns voiced by many well-respected authors, practitioners and thought leaders. Who, whilst acknowledging that one of the strengths of SAFe is its basis in Lean principles have raised concerns about whether the framework actually supports the principles and values which underpin Agile, or whether it undermines them [23]. A focus on standardisation, large scale planning and taking a top-down approach are also highlighted as potential problems, primarily due to an apparent focus on process rather than on people [24]. SAFe claims to present approach to scaling Scrum, yet Ken Schwaber one of the designers of Scrum argues that SAFe is based on RUP rather than Scrum [25]. Ron Jeffries one of the original designers of XP also highlights the centralised approach to planning dictated by SAFe as an issue [26].
  Both DaD and SAFe add new rituals, practices and other modifications to existing Agile methods, both propose significant organisational change and both claim to address corporate governance issues; DaD through blending traditional and Agile thinking and SAFe though offering transformational patterns as a bridge from traditional to Lean-Agile approaches. All the frameworks discussed in this post are associated with large amounts of expensive supporting material, such as, training courses, certification schemes, supporting software products and of course highlight the need for specialist consulting as a pathway to success.
  These frameworks are primarily designed to assuage the concerns of organisational governance teams who are keen to leverage the perceived benefits of Lean and Agile approaches, whilst mitigating a myriad of well-documented inherent risks. Whilst all these frameworks emphasise adaption to meet the needs of implementing organisations, they are presented as highly prescriptive pathways to success and unlike Agile implementations at the team level there is very little empirical evidence in the substantive literature to support claims that these approaches are proven or that they represent a good investment of potentially very large amounts of money. More conceptual approaches such as Lean governance and those associated with Agile in-the-small, (meaning the use of specific practices such as XP, pair programming, BDD and TDD) are well researched and there exists a great deal of empirical evidence to support the idea that in various circumstances, these practices can deliver benefits; but on their own they are not sufficient.
  The way forward
  So what is the way forward? How can organisations take advantage of Agility to help them respond to new and rapidly evolving demands and opportunities, whilst continuing to minimise risk, and meet their obligations to stakeholders? The research on organisations which have implemented Agile-in the large still presents us with more questions than answers [27] ; however we can identify some of the organisational characteristics which seem to influence perceptions of success.
  Key amongst these is the need for a shared understanding of what Agility actually means along with clarity of purpose from an organisational governance perspective [7]. For example if your goals are around increasing speed to market or making improvements to product quality within an existing culture and governance framework, then a structured approach or framework will probably be appealing. Especially if that framework also suggests that you can do these thing more efficiently (cheaply) by adopting it. But this is not Agility; this is procedural change and much of the existing research suggests that organisations that confuse Agility and process improvement will not be satisfied with the outcomes nor will they achieve the certainty they desire. If, on the other hand, your goal is to deliver value to your customer through understanding and responding to their needs you are not only starting from a different place but will need to take a very different approach. Structuring your organisation around this goal can require a seismic shift to an organisations culture and management style. Wanting to be better able to respond to an uncertain and disrupted marketplace demands a level of tolerance for uncertainty that many organisations struggle with.
  In addition to a shared vision and clarity of purpose, the characteristics shared by organisations that perceive themselves to have been successful in this regard are:
  An understanding that the biggest challenges are likely to be around people, perceptions and concepts rather than technical [5]
  A willingness to iteratively experiment and to learn
  A culture that engages and empowers both employees and customers to be part of the experiment and learn cycle
  Transparency in everything, including things which don’t work
  Patience; being willing to start small, measure and build on small improvements in customer value, and employee satisfaction
  Conclusion
  Enterprise level Agile is not well researched or understood and whilst many of the challenges associated with scaling Agile have been identified, approaches to solving them are emergent and potentially immature. Whilst frameworks such as DaD and SAFe which propose step-by-step approaches to implementation may seem appealing and present attractive testimonials and case studies to support their claims, these claims are not based on empirical research and in many cases are at odds with the empirical evidence which is available.
  References
  [1]       K. Conboy, “Agility from First Principles: Reconstructing the Concept of Agility in Information Systems Development,” Inf. Syst. Res., vol. 20, no. 3, pp. 329–354,478, 2009.
  [2]       K. J. Riemer B., “Digital Disruption,” Backed By Research, 2014. [Online]. Available: https://byresearch.wordpress.com/2013/03/07/digital-disruption/.
  [3]       S. Girn, “Digital Disruption – Opportunities for Innovation and Growth.” Reserve Bank of Australia, 2014.
  [4]       P. Adamczyk and M. Hafiz, “The Tower of Babel did not fail,” ACM SIGPLAN Notices, vol. 45, no. 10. ACM, Reno/Tahoe, Nevada, USA, p. 947, 2010.
  [5]       B. Boehm and R. Turner, “Management challenges to implementing agile processes in traditional development organizations,” Software, IEEE, vol. 22, no. 5, pp. 30–39, 2005.
  [6]       S. C. Misra, U. Kumar, V. Kumar, and G. Grant, “The Organizational Changes Required and the Challenges Involved in Adopting Agile Methodologies in Traditional Software Development Organizations,” in Digital Information Management, 2006 1st International Conference on, 2007, pp. 25–28.
  [7]       A. Mahanti, “Challenges in Enterprise Adoption of Agile Methods -- A Survey,” J. Comput. Inf. Technol., vol. 14, no. 3, pp. 197–206, 2006.
  [8]       G. Van Waardenburg and H. Van Vliet, “When agile meets the enterprise,” Inf. Softw. Technol., vol. 55, no. 12, pp. 2154–2171, 2013.
  [9]       C. Rand and B. Eckfeldt, “Aligning strategic planning with agile development: Extending agile thinking to business improvement,” in Proceedings of the Agile Development Conference, ADC 2004, 2004, pp. 78–82.
  [10]     K. Logue and K. McDaid, “Agile Release Planning: Dealing with Uncertainty in Development Time and Business Value,” in Engineering of Computer Based Systems, 2008. ECBS 2008. 15th Annual IEEE International Conference and Workshop on the, 2008, pp. 437–442.
  [11]     V. Heikkilä, K. Rautiainen, and S. Jansen, “A revelatory case study on scaling agile release planning,” in Proceedings - 36th EUROMICRO Conference on Software Engineering and Advanced Applications, SEAA 2010, 2010, pp. 289–296.
  [12]     K. Power, “The Agile Office: Experience Report from Cisco’s Unified Communications Business Unit,” in Agile Conference (AGILE), 2011, 2011, pp. 201–208.
  [13]     P. Saddington, “Scaling agile product ownership through team alignment and optimization: A story of epic proportions,” in Proceedings - 2012 Agile Conference, Agile 2012, 2012, pp. 123–130.
  [14]     J. Pernstål, R. Feldt, and T. Gorschek, “The lean gap: A review of lean approaches to large-scale software systems development,” J. Syst. Softw., vol. 86, no. 11, pp. 2797–2821, 2013.
  [15]     S. Ambler, “Disciplined Agile Delivery,” 2014. [Online]. Available: http://disciplinedagiledelivery.com/.
  [16]     “Large Scale Scrum (LeSS),” 2014. [Online]. Available: http://less.works/less.
  [17]     “Scaled Agile Framework,” 2014. [Online]. Available: http://scaledagileframework.com/.
  [18]     S. Ambler, “Enterprise Unified Process (EUP): Strategies for Enterprise Agile,” 2014. [Online]. Available: http://enterpriseunifiedprocess.com/.
  [19]     “IBM Rational Unified Process (RUP),” 2014. [Online]. Available: http://www-01.ibm.com/software/rational/rup/.
  [20]     A. W. Brown, S. Ambler, and W. Royce, “Agility at scale: economic governance, measured improvement, and disciplined delivery,” in Proceedings of the 2013 International Conference on Software Engineering, 2013, pp. 873–881.
  [21]     D. Leffingwell, “Dean Leffingwell,” 2014. [Online]. Available: http://deanleffingwell.com/.
  [22]     P. Saddington, “The Scaled Agile Framework (SAFe) - A Review | Agile ScoutAgile Scout,” 2014. [Online]. Available: http://agilescout.com/scaled-agile-framework-safe-review/.
  [23]     N. Killick, “The Horror Of The Scaled Agile Framework | neilkillick.com,” 2012. [Online]. Available: http://neilkillick.com/2012/03/21/the-horror-of-the-scaled-agile-framework/.
  [24]     A. Elssamadisy, “Has SAFe Cracked the Large Agile Adoption Nut?,” InfoQ, 2014. [Online]. Available: http://www.infoq.com/news/2013/08/safe#.
  [25]     K. Schwaber, “unSAFe at any speed,” Telling it Lite it is, 2014. [Online]. Available: http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/.
  [26]     R. Jeffries, “SAFe â€“ Good But Not Good Enough | xProgramming.com,” 2014. [Online]. Available: http://xprogramming.com/articles/safe-good-but-not-good-enough/.
  [27]     D. Torgeir, B. M. Nils, T. Dingsoyr, N. B. Moe, T. Dingsøyr, and N. B. Moe, “Research challenges in large-scale agile software development,” SIGSOFT Softw. Eng. Notes, vol. 38, no. 5, pp. 38–39, 2013.
- As an agile business analyst, I want...
  
  Jul 26, 15
  
  Don't be a story monkey
- The words and pictures we use to describe things...
  
  Jun 23, 15
  
  ... conceal as much as they show.
  
  An insighr from this very interesting article.
- An investigation into Self Organisation
  
  May 29, 15
  We ran a meetup session with the local Scrum User Group discussing Holocracy, a model for self-organizing teams. After the discussion about Holocracy led by Julian Waters-Lynch, we then ran an activity exploring our own appetite for self-organisation.
  
  I’ll share what came out of the discussion in two future posts;
  How self-organised do we think we are, and what’s holding us back
  How self-organised do we want to be, and what will signal success.
  I asked the room to take two different coloured index cards (green and yellow if you must know) and the gave people two jobs.
  
  On the yellow cards I asked people to rate their current organisation's level of self organisation from 1 (low) to 10 (high.) I then asked them to write down some points on what holds them back.
  
  Then, on the green cards, I asked people to rate their aspiration for self organisation (same scale) and to write down what they would see as signals of success.
  
  I have plotted the scores in the chart below.
  
  This is from a group of people who are curious and motivated enough to come out to a work themed event at 6pm on a weeknight, so they are at least somewhat engaged at work.
  
  I personally can't read much from the chart alone except that there is a wide spread of answers to the question and that most people's aspirations live around the 7-8 out of 10 mark. Perhaps this is a natural conservatism, or simply a focus on next stages of growth.
  
  So in the next few days I will post more, showing what comments people said in the context of what scores they were giving.
- BA Effectiveness survey
  
  May 21, 15
  I am running an NPS like survey on Business Analysts. I'd appreciate your sharing this out to your professional network. What do people think about Business Analysts?
  
  So far I have close to 100 responses and there is a pretty positive set of feedback. The comments are interesting as well.
  
  I want more though and I need your help. Share this out for me.
  
  http://bit.ly/1JRnYGc
  
  I'll publish the results here in August.
- Agile; an unfinished epiphany
  
  May 16, 15
  
  Kelsey van Haaster
  May 16th 2015
  
  Earlier this week, I was giving a talk about Agility and how the ideas behind it might scale to an organisational level, when I was asked the following question;
  
  Agile Business Analysts and Product Owners Meet-up Group
  Visual notes by Lynn Cazaly
  Feb 2015
  “I had understood that the idea of Agile was in fact under review and that people are questioning some of the ideas behind it, particularly around the usefulness of some of the practices … what do you think about that?”
  
  I was initially surprised by the question, but gathered myself together sufficient to say; "well yes, it’s Agile it’s supposed to be reflexive; it’s supposed to evolve; it’s not a problem."
  
  But thinking about this further, I realise that there is a problem, but it’s not a problem with Agile, it’s a problem with us and with over complication.
  
  The following quote from an excellent post by Andy Hunt pretty much nails it.
  
  “So instead of looking up to the agile principles and the abstract ideas of the agile manifesto, folks get as far as the perceived iron rules of a set of practices, and no further.”
  
  In his post Andy Hunt goes on to propose that the waters are now so muddy that we need a new name and new set of principles in order to distance ourselves from the mess and resolve this problem. Somehow though, I don't think a new name or a new version will fix things, I worry that it would just add to the complexity.
  
  There are a number things floating around the internet at the moment that reflect this such as thistalk from Erik Meijer. When this talk was published it caused a whole lot of consternation exemplified by these two very different responses to Meijer, one, which addressed his arguments piece by piecee and another with suggested he was actually pulling off a hoax. None of which really helps to clarify the situation much.
  
  Much of the criticism of current interpretations of Agility is related to the implementation/use (misuse) of so-called Agile methods and tools. This is unsurprising, since whilst these can give you a starting point through which to approach a task or a problem; they can, and sometimes are, used in such a way that they become instruments of torture.
  
  But these are not the problem either, the problem is us! Our understanding of Agility is at the Shu and (sometimes) Ha level; even after 15 years we have not yet become confident enough to let go of the need to put up a methodological scaffold to which we can attach a safety harness. This is exemplified by the current popularity of Agile frameworks, designed to help organisations with something that looks like it needs simplification.
  But Agile thinking is already very simple, the ideas in the Manifesto are not meant to be constraining, they are meant to free us up to work using whatever tools and techniques work, in whatever way they work best, for a given set of circumstances. We will only have reached the Ri level understanding once we can do this. Then, we will have really understood that Agility is not about working with technology, business or software; Agility is about working with people.
- Product Owner, Updated
  
  May 13, 15
  
  How would I describe a Product Owner?
  
  I am writing this description in response to the below Mkie Cohn description of a Product Owner. Mike's description isn't wrong per se, but it is almost ten years old and maybe can do with a refresh. I'll qualify this description by saying that there are actually many incarnations of the role, and my view is locking things down to one model is useful for recruiters and beginners, but should quickly fall away in deference to the context and strengths of the people in play on any particular team.
  
  Mike Cohn's description of a Product Owner is here. You might like to evaluate the differences between that description and this one - and comment on your opinions here.
  
  I have italicized paragraphs where I have copied from Mike's description verbatim. The way I put this together was by pasting his description in and writing over the top, deleting the old stuff as I went, so there are often similar phrases, as well as the same pattern or shape of the description.
  Product Owner description
  The Scrum product owner is member of a development team with a particular set of responsibilities or focus areas. Part of the product owner responsibilities is to ensure the team have a vision of what he or she wishes to build, and convey that vision to the customers and user community perhaps with the help of sales and marketing people.
  
  This shared vision is key to successfully starting any agile software development project. The agile product owner does this in part through managing the product backlog, which is a prioritized features list for the product. The product owner may take an autocratic or facilitative style of management, depending on the context the team is working in.
  
  The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed.
  
  This, of course, varies tremendously based on whether the team is developing commercial software, software for internal use, hardware or some other type of product. The key is that the person in the product owner role needs to be able to articulate a vision for what is to be built, both to the team and to stakeholders to the development work.
  
  The PO will come prepared to sprint plans with a view on what should be top of the priority list, but be ready to negotiate with the team on the actual choices of what is to be done based on both his or her insights about customer demand and the advice and knowledge the development team bring based on capabilities, opportunity and data that feeds directly to the team. Product owners will bring ‘voice of customer’ but will also facilitate and perhaps arbitrate on the choices of what is to be done with the team.
  
  Product Owners should participate in sizing backlog items and should share their views on whether a job should be hard, easy, complex or simple. Their contributions in this discussion will help inform a development team of the rough value of the work, and help understand appropriate limits to investment in jobs.
  
  Product owners should have skin in the game and so, if they publish forecasts about when the work will be done they should be accountable for those outcomes. As far as the admin of creating and publishing forecasts - it makes sense that the PO does it rather than the engineering team, as the PO knows (or should know) the audience and the way they best hear messages. One person is also better able to manage external relationships that a group, as one on one discussions are more intimate than group ones.
  
  A good product owner works with the team on establishing reliable forecasting capability. If the work is inherently risky that should be managed as part of the conversation. Great teams share accountability for results to stakeholders and customer, and to each other.
  
  A good product owner understands that delivery of work is not always linear. Forty stories will not be evenly delivered over four weeks. There is inherent variation in work. Good product owners study variation and account for it in planning and managing expectations.
  
  Motivation is intrinsic, so a Product Owner can’t fundamentally motivate team members, but a Product Owner has a unique opportunity to inspire the team with feedback and insights from the market. Broadly, Autonomy, Mastery and Purpose are what motivates people, so Product Owners should be thinking about how to max out these attributes for the team, and for themselves.
  
  One good practice Product Owners can share with teams is helping elevate sprints by highlighting the big goal the work is contributing to, and how the work will solve real customer problems.
  
  Product Owners know the importance of a stable set of goals, and understand the cost of changing plans and context switching too frequently. Product Owners will do their best to give the development team a stable set of goals for a planning horizon that is appropriate to the team. This can be played out at the daily, sprint, release and project level. Despite the importance of stable contexts, Product Owners also understand that effectiveness trumps efficiency and so will work with the team on addressing urgent and important new information appropriately.
  
  Product Owners need to come with decision making authority and expertise in the work they do. That expertise can be either built around market and customer experience and insight or the techniques and practices and processes of customer discovery, analysis and design, or ideally both. Great product owners understand the need to bring an approach that balances data, systematic approaches and the emotional appeal of customer stories.
  
  From a development team’s point of view a good product owner is one that works full time with a team. Some product owners manage a portfolio of products and work with several teams. Access to information and decisions quickly and high context communication are what is most important. Product Owners will work with the team to optimize the balance of outward facing activities and team facing activities for the greatest good.
  
  Finally, a great Product Owner takes time to share and promote the good work a team is doing across the home organisation and market place as well as bring voice of customer to the team. A great product owner wants to have the broader community at work to appreciate the great contributions their team is making.
- All Quadrants, All Levels!
  
  May 03, 15
  I am revisiting the AQAL model. I looked at it a few years ago and found it overwhelming. It seemed overly complicated, hard to parse and not easily actionable. In the years since I am more able to make sense of it, but it's taking work.
  
  Some of the challenges;
  It feels shamanistic and I come from a (probably overly) rational path, and so it is easy to get skeptical and want to walk away from the reading and understanding. Even framing that sentence probably rules investigation out to a bunch of people.
  The meme isn't there. The secret to Scrum was the simple meme that enabled it to travel from person to person and be easily reproduced. AQAL doesn't have an easily transferable idea, at least not one I have found yet.
  It has some brilliant ideas, but you need to have a certain degree of background knowledge for them to make sense. I might sum up Anti-fragile as 'you need skin in the game to approach things in a mindful way' (and I am sure that is a huge injustice right there) but I don't have that simple real world metaphor for AQAL... yet.
  I have limited time, what with life and all, so struggle to get the time to read enough. (Are there any experienced people in or around Melbourne who want to talk over lunch?)
  It frames things like Spiral Dynamics and Holocracy, so it is an influential model that needs understanding, but the links to these other ideas often require another investment in time and thinking to have a rounded perspective
  If you go there, will you end up alone? To hat degree does this knowledge isolate you from the community of people you work for and with?
  I also worry that it might end up being a framework that explains things, but doesn't help me make better decisions, as it is so complicated to comprehend.
  
  That list doesn't make AQAL wrong. It just means it is hard work.
  
  Here is an introduction essay on the topic (pdf).
  
  Here is a picture to prove my point about complicated-ness. Got any advice?
- Agile Project Management Course | 14-15 may via Swinburne University
  
  Apr 30, 15
  
  Come to my course on Agile Project Management later this month via Swinburne University.
  
  It is fun, informative and pragmatic. All good things, right?
  
  You can sign up here!
  
  The course runs in Melbourne CBD on 14-15th May.
  
  The content runs through some basic "What is Agile" and then through a handful of popular agile frameworks. It also looks at how the agile way of working intersects with the role of the project manager and how a project manager can shift the way they work to deliver more reliable and higher value project outcomes.
  
  Its a pretty good two days and I reckon worth your while if you are experienced or a beginner in ether the project delivery or agile delivery business.
  
  Sign up! Oh - and share it out for me to your network.
- Microservices for the rest of us.
  
  Apr 23, 15
  
  Microservices: An Accessible Overview
  By Kelsey van Haaster
  
  If your work were remotely associated with software development, it would have been difficult for you to miss the recent excitement and discussion in the tech world about the term Microservices. Much of this discussion has been in the context of the underlying tech, software architectures, development techniques and cloud-based services. The conversation has been conducted mostly within technical forums, blogs and meet-ups. As a consequence, you may have felt that this was a purely technical discussion of little relevance to your work, or you may have been put off engaging in the discussion because you don’t identify yourself as sufficiently technical. Neither of these things is correct, this is not only about gnarly tech stuff and you don’t need to be a gnarly (or not) tech person to engage in the discussion, so read on and join the conversation.
  
  What does the term Microservices mean?
  To the non-tech person, when the tech folk are talking about microservices they are referring to a way of thinking about how software (usually) services are architected, created and delivered. It’s not about a particular tool set, or package and doesn’t require a specific skill set. Using a Microservices approach to strategic delivery has both practical and strategic implications the whole IT team, including business analysts, project managers, product managers.
  
  What is a Microservice?
  
  It’s probably easier to start off with a description of what a microservice is not.
  
  We are all familiar with the concept of a big enterprise system that does everything, for example, ERP systems, like SAP, or CRM systems such as Salesforce. These kinds of applications are called monoliths, they are a one stop shop for a whole lot of different things and have the goal of standardising things, such as how data is managed and how things travel through workflows and processes. This results in a lot of very complex data transformations going on. These monolithic applications are often supported by a central data warehouse, a repository for massive amounts of corporate data, which is processed and repackaged so that it can be used for various things, e.g. monolithic applications or to support financial reporting, or data mining.
  
  These things are not microservices!
  
  A microservice is a self-contained system that is designed to do one thing really well. Taking a microservices approach to systems architecture means building multiple microservices to provide the various functions needed by a business.
  
  Cross-functional teams focused on building a product, which meets a specific business need, rather than a general one, develop Microservices. The idea being that the same team will develop and maintain the microservice throughout its lifespan. Microservices are as self-contained and decoupled as possible from other services or applications. Microservices are designed to be smart enough to do all their own data processing so using multiple microservices to do different things avoids the need to create complex interfaces between them.
  
  What are the benefits of microservices?
  
  The main benefits of microservice approaches are found in reduced dependency between systems and therefore reduced risk associated with change. Many of the monolithic applications mentioned earlier require very specialised skills to manage and maintain them. They represent silos of knowledge in the business and when one of them has a problem, the amount of inherent coupling they imply can bring everything to a grinding halt. These monolithic systems are also expensive and difficult to implement, (anyone recall their last ERP project). For smaller organisations, the size and cost of these systems can be a significant barrier to implementing them.
  
  Because of the decoupled nature of microservices, you can do some pretty cool tech things that can save a lot of time and money too. For example, you could develop a microservice to receive data from multiple sources by email, process it and make the published data available for report generation. You can develop your microservice in such a way that it is triggered only by the arrival of new data. This kind of thing has important implications for both small and large organisations. Large organisations could employ this kind of strategy multiple times to meet specific reporting needs. Multiple targeted, self-contained and minimally coupled services can reduce the costs, overheads and bottlenecks associated with maintaining central data processing and reporting functions. For smaller organisations, microservices can provide a lower cost, lower risk way to develop and deploy services.
  
  Implications for the BA/PM
  
  The decoupled, flexible and independent nature of a project using a microservices approach means that the BA and PM may be able to spend less time managing complex stakeholder relationships around the external interfaces of the project. Microservices are small systems, that do one thing, this means that the stakeholder group may be smaller and more aligned. Tighter scope, small teams and small stakeholder groups support continuous discovery, development, and feedback. What’s not to like?
  
  For those who want to read a more detailed description the following is a good start:
  
  http://martinfowler.com/articles/microservices.html
Tweets

Tweets

Profile
- RT @melbfestival: Bring along your own personal mementos and create a living sculpture with artist Hiromi Tango. Workshop info here: https:…
  
  Sep 23, 16 from Twitter for Android Reply, Retweet, Favorite
- The decline of io9 https://t.co/2oCObTROAh
  
  Sep 20, 16 from Twitter for Android Reply, Retweet, Favorite
- @agilejitsu six weeks means better innovation. But do you *really* want innovation or would you rather one week sprints?
  
  Sep 20, 16 from Twitter for Android in reply to agilejitsu Reply, Retweet, Favorite
- https://t.co/ObtokVPNRM
  
  Sep 15, 16 from Twitter for Android Reply, Retweet, Favorite
- Agile will never work here https://t.co/n75swMGLyf #pmot #baot
  
  Sep 13, 16 from twitterfeed Reply, Retweet, Favorite
- If you could simplify your organisation's processes to this... https://t.co/1aGZgbS2bv
  
  Sep 13, 16 from Twitter for Android Reply, Retweet, Favorite
- @tookwancottage he he. Making it people centred is the key to success. Chat over a beer sometime
  
  Sep 13, 16 from Twitter for Android in reply to tookwancottage Reply, Retweet, Favorite
- @scottwambler speaking at the #agile #melbourne dinner tonight https://t.co/RSwTtj72IB
  
  Sep 13, 16 from Twitter for Android Reply, Retweet, Favorite
- @scottwambler Scott can you give me a call? (see email)
  
  Sep 13, 16 from Twitter for Android Reply, Retweet, Favorite
- @DanielHooman sorry no :)
  
  Sep 12, 16 from Twitter for Android in reply to DanielHooman Reply, Retweet, Favorite
- Dinner with Scott Ambler in Melbourne next week https://t.co/3PsfJMj1Rw
  
  Sep 09, 16 from Twitter for Android Reply, Retweet, Favorite
- I could just about delete this app now.
  
  Sep 08, 16 from Twitter for Android Reply, Retweet, Favorite
- @agileeddie *lads
  
  Sep 06, 16 from Twitter for Android in reply to brown_note Reply, Retweet, Favorite
- @agileeddie do the laws a favour and write a review on Amazon
  
  Sep 06, 16 from Twitter for Android in reply to agileeddie Reply, Retweet, Favorite
- @agileeddie glad you like it. :)
  
  Sep 06, 16 from Twitter for Android in reply to agileeddie Reply, Retweet, Favorite
- Who has read the Heretic's Guide to Management yet? https://t.co/EgB82m4caK
  
  Sep 05, 16 from Twitter for Android Reply, Retweet, Favorite
- “Cognitive bias cheat sheet” @buster https://t.co/nv90xzEOtT #pmot #baot
  
  Sep 05, 16 from twitterfeed Reply, Retweet, Favorite
- “Cognitive bias cheat sheet” @buster https://t.co/Q2doLoYgZ3 #pmot #baot
  
  Sep 05, 16 from twitterfeed Reply, Retweet, Favorite
- @alshalloway Snowden includes the notion of sense making on all his talks and I think it's here on his hit single https://t.co/bDQl2WgSzC
  
  Sep 05, 16 from Twitter for Android in reply to alshalloway Reply, Retweet, Favorite
- RT @swear_trek: INTERNET!!!!!! https://t.co/Po6yT0O8Mr
  
  Sep 04, 16 from Twitter for Android Reply, Retweet, Favorite
Posts

Posts

Feed
- Heart of Agile - lightning talk
  
  Jul 26, 16
  
  I presented a lightning talk at LAST Conference Sydney, July 2016. In it I also talked about harnessing ambiguity - as I am reading Kailash and Paul’s book "The Heretic’s Guide to Management" which is a great read full of useful insights.
- Recruiting agile vs agility sportsbet_feb2016
  
  Feb 29, 16
  
  Nadia Smith presented this discussion on recruiting in agile organisations at 1st Conference, 15th February 2016.
- Good to Great strengthfinder workshop for teams
  
  Aug 14, 14
  
  Good to Great strengthfinder workshop for teams
- Collaboration: Cockburn's Dance of Contribution in a Workshop
  
  Jun 04, 13
  
  This is a presentation which accompanies a workshop on Alistair’s "Collaboration; The dance of Contribution" article. You can read the article here: http://alistair.cockburn.us/Collaboration%3A+the+dance+of+contribution The workshop includes two games as well as a description of what leadership behaviours matter when you move from a compliant or merely co-operative culture to a collaborative one.
- Melbourne agile and scrum sig slides v01-00
  
  Sep 26, 12
  
  Presentation by John Giles to Melbourne Scrum User group. From 26 Sept 2012
- How to Start a Project
  
  Apr 04, 12
  
  What should you consider when starting a project? What models and aprpaoches can help get you off to a good start?
- Story mapping introduction short version
  
  Feb 17, 12
- Agile values
  
  Oct 04, 11
  
  We ran a lunchtime session talking about values and how they underpin the way we work. The session closed out with a whiteboard exercise which is described on the last page of this deck. If you use this I’d appreciate your sharing your experiences and feedback via the comments or by email. Thanks!
- Requirements & scope
  
  Aug 07, 11
  
  I gave this talk at PMOZ last week.
- Requirements = Scope
  
  Jun 01, 11
  
  This is a short introduction presentation for the PMOZ conference in Sydney later this year.
- Requirements = Scope, BA World Bengaluru 2011
  
  May 29, 11
  
  In May 2011 I presented this discussion of why project scope is driven by requirements, how requirements change is inevitable, and how that makes good project estimates very difficult. I then present one useful technique for managing this challenge.
- Starting a new project using Scrum
  
  Apr 12, 11
  
  I gave this to the Melbourne Scrum Users Group. It was an interesting group with a few experience scrum users and many inexperienced people via the ACS, so the talk had to accommodate some Scrum 101 stuff, and went longer than planned with me talking for a bit over an hour. In the end it went well, and I hope I get some feedback from the audience via the meetup site and ACS website.
- Ba tips: the complexity of workshops
  
  Jan 22, 11
  
  When Business Analysts take their analysis and recommendations to stakeholders, we often use workshops. There is a trap in the workshop. You can only fit so much communica
- Scrum 18 months later
  
  Aug 05, 10
  
  Where are we 18 months after the teams adopted scrum. Where do we want to go?
- How Business Analysts Can Re Invent Themselves For An Agile World
  
  Sep 23, 09
  
  a presentation on how a business analyst can fit themselves into an agile/scrum project. Comments very welcome.
- Business Analyst As Product Owner
  
  Jul 03, 09
- Kano Analysis and Software Requrements
  
  Jun 13, 09
  
  Using Kano Analysis to prioritise Business Requirements Noriaki Kano, recipient of the Deming Prize, developed a model to work out what stakeholder requirements are mandatory, which ones are value for money proposition (i.e. more is better,) and which requirements will delight them. This talk introduces the Kano model in the business/software requirements context, and presents a step by step application of the model so that you can delight your stakeholders.
- How To Assess Project Proposals
  
  Feb 19, 09
  
  Some notes on how to assess a project brief or business case proposal. Don’t buy what you hear on face value.
- How To Review Software Requirements
  
  Feb 12, 09
  
  A guide on how to review and give feedback to business requirements documents for software projects.
- Software Project Methods
  
  Jan 16, 09
  
  A summary of the more popular software develpment processes and methods.
Posts

Posts

Feed
- Business agility: Beyond software teams
  
  Sep 14, 16
  
  Melbourne Agile and Scrum User Group
  
  Topic: A discussion of how far beyond software development this agile thing is getting.
  
  Software product team agility is one part of a bigger system. It's useful to improve, but is this the bottleneck holding back your organization?
  
  Let's look wider and see what opportunities there are.
  
  Format: Panel discussion
  
  If you want to be on the panel get in touch.
  
  We are after your stories of what you have done, participated in and seen with regards to agile methods, practices and values being applied beyond software product development teams.
  
  What lessons can be shared to help each other.
  
  Panel so far:
  
  Host: Eduardo Nofuentes
  
  Murray Robinson - can talk about how the IE Agency board use agile practices to manage the company
  
  Melanie Starr - can talk about her work in government policy and corporate comms roles
  
  Melbourne - Australia
  
  Wednesday, September 28 at 6:00 PM
  
  131
  
  http://www.meetup.com/scrum-12/events/231157511/
- Agile Values discussion
  
  Aug 22, 16
  
  Melbourne Agile and Scrum User Group
  
  Agile, Scrum, XP and Kanban all introduce themselves by starting with values. This session is a facilitated discussion that will;
  
  1. Introduce the values of each of the above models.
  
  2. Describe why thinking about and attending to values is integral.
  
  3. Break into an exploration of where a focus on the values has helped, and where a failure to attend to values has hindered people.
  
  4. A shared commitment to action. Let's all focus on taking the values back to work to help teams be successful.
  
  Hosted by Craig Brown and a person as yet un-named.
  
  Melbourne - Australia
  
  Wednesday, October 26 at 6:00 PM
  
  95
  
  http://www.meetup.com/scrum-12/events/231155821/
- The annual Agile Tools meetup
  
  Jun 03, 16
  
  Melbourne Agile and Scrum User Group
  
  Providers of tools come together at this meetup and show you how they work and how they add value.
  
  Specific details of the format are yet to be arranged, but if you have something you want to showcase please let us know in the comments below!
  
  Melbourne - Australia
  
  Wednesday, November 30 at 6:00 PM
  
  28
  
  http://www.meetup.com/scrum-12/events/231467060/
- Closed for Christmas
  
  May 16, 16
  
  Melbourne Agile and Scrum User Group
  
  No event due to holidays.
  
  Melbourne - Australia
  
  Wednesday, December 28 at 6:00 PM
  
  http://www.meetup.com/scrum-12/events/231155914/
- Summer catch up
  
  May 16, 16
  
  Melbourne Agile and Scrum User Group
  
  A social session to catch up and talk about goals for the year ahead.
  
  Things that need doing;
  
  1. Leaders sign up to arrange speakers and venues
  
  2. Pre-book venues where you can
  
  3. Consider a 2-3 month roadmap of talks (with occasional breaks to make room for opportunities.)
  
  Melbourne - Australia
  
  Wednesday, January 25 at 6:00 PM
  
  1
  
  http://www.meetup.com/scrum-12/events/231155938/
- Scrum Monthly Meet-up
  
  Apr 15, 15
  
  Melbourne Agile and Scrum User Group
  
  TBC. Suggest a topic
  
  Melbourne - Australia
  
  Wednesday, February 22 at 6:00 PM
  
  1
  
  http://www.meetup.com/scrum-12/events/hvkpglywdbdc/
Posts

Posts

Feed
- Themes, Epics, Stories, Tasks. Navigating the confusion.
  
  Aug 23, 16
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Hosted by Helen Snitkovsky.
  
  Helen is a veteran of the agile movement. She's a consultant and coach, She is a former start-up co-founder and CTO. She is a seasoned project and program manager as well. Helen is very respected and admired by teams she has coached and is described as a passionate and inspiring leader.
  
  Things to address this month;
  
  Themes, Epics, Stories, tasks; Navigating the confusion
  
  • What are they and their relation to each other?
  
  • Who does what, when and where?
  
  As usual we need a volunteer for the venue. We will adjust the RSVP number when we know the venue.
  
  Cremorne VIC 3121 - Australia
  
  Tuesday, October 11 at 6:00 PM
  
  60
  
  http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/231974255/
- Suggest a topic. What question do you want answered?
  
  Sep 02, 15
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Folks this meetup runs on community. So if you have a suggestion for a session be bold and program it in.
  
  Anyone can edit and update these sessions. Just click, type something and see what happens.
  
  Melbourne - Australia
  
  Tuesday, November 8 at 6:00 PM
  
  5
  
  http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/233203395/
- Suggest a topic. What question do you want answered?
  
  Sep 02, 15
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Folks this meetup runs on community. So if you have a suggestion for a session be bold and program it in.
  
  Anyone can edit and update these sessions. Just click, type something and see what happens.
  
  Melbourne - Australia
  
  Tuesday, December 13 at 6:00 PM
  
  3
  
  http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/233253465/
- Suggest a topic. What question do you want answered?
  
  Sep 02, 15
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Folks this meetup runs on community. So if you have a suggestion for a session be bold and program it in.
  
  Anyone can edit and update these sessions. Just click, type something and see what happens.
  
  Melbourne - Australia
  
  Tuesday, January 10 at 6:00 PM
  
  http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/229495583/
- Suggest a topic. What question do you want answered?
  
  Sep 02, 15
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Folks this meetup runs on community. So if you have a suggestion for a session be bold and program it in.
  
  Anyone can edit and update these sessions. Just click, type something and see what happens.
  
  Melbourne - Australia
  
  Tuesday, February 14 at 6:00 PM
  
  http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/brclklywdbsb/
- Suggest a topic. What question do you want answered?
  
  Sep 02, 15
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Folks this meetup runs on community. So if you have a suggestion for a session be bold and program it in.
  
  Anyone can edit and update these sessions. Just click, type something and see what happens.
  
  Melbourne - Australia
  
  Tuesday, March 14 at 6:00 PM
  
  http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/brclklywfbsb/
- Suggest a topic. What question do you want answered?
  
  Sep 02, 15
  
  Agile Product Owners and Business Analysts, Melbourne
  
  Folks this meetup runs on community. So if you have a suggestion for a session be bold and program it in.
  
  Anyone can edit and update these sessions. Just click, type something and see what happens.
  
  Melbourne - Australia
  
  Tuesday, May 9 at 6:00 PM
  
  http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/231558308/
Info

Info

Profile
- Craig Brown
  
  VP, Collaboration at Aconex. Co-founder of LAST Conference.
  
  Management Consulting | Melbourne, Australia, AU
  
  Summary
  
  Craig’s roles over the past 15 years have involved leading project management teams, projects and programmes, consulting, training and coaching in a variety of aspects of project delivery. Most recently Craig was a program manager on Telstra’s Customer Advocacy journey, working with culture change, Net Promoter Scores, and lean-style customer centred process improvements.
  
  Apart from the disciplines of project and portfolio management Craig is also an Agile and Lean enthusiast with a focus on the collaboration and cultivation aspects of agile practices and methods. Craig runs the Melbourne Scrum User group and also runs meetup groups for Agile business analysis and agile project managers where he helps people navigate their way from traditional roles and thinking to modern ones.
  
  Craig also co-created the LAST conference which is a low cost community driven conference focusing on lean, agile and systems thinking.
  
  Experience
  - Sept 2013 - Present
    Team member / Aconex
    
    Aconex is growing and it’s an exciting time at one of Australia’s most successful Saas product businesses. We are a global company, headquartered in Melbourne, and we are making a difference to the way the world of construction, infrastructure and ‘big engineering’ works and collaborates.
    
    We are an amazingly enthusiastic team. Everyone learns, everyone helps shape the work. We focus on high quality engineering practices. Competency is highly valued. An agile way of working is so ingrained we barely remember to talk about it in job ads.
    
    We have an extremely friendly and welcoming environment. Our culture is important to us. We have a flat hierarchy and expect people to do what they think is right without asking permission. We share skills and knowledge through a pattern of regular internal meetups.
    
    The CEO/Founders come and hang out with us in the well appointed kitchen on Friday nights. Our Engineering teams thrive in an environment of continuous learning, development and collaboration.
    
    People that work here feel proud of their work and proud of the people they work with.
  - Jul 2013 - Present
    Community Builder / Tabar
    
    Bringing people together to do great work together.
    
    In this capacity I curate LAST Conference, Deliver Management 3.0 and other Agile training, run Agile community of practice groups and help teams improve the way they work.
  - Jul 2012 - Present
    Co-founder / LAST Conference
    
    LAST Conference Melbourne is a one day, affordable, grassroots mini-conference for Lean, Agile, and Systems Thinking practitioners. The schedule encourages participation and interaction via talks, workshops and activities.
    
    We always have lots going on at once, and our aim is that by the time you get to the end of event drinks, you’ll be tired, yet buzzing with inspiration about the ideas exchanged with your fellow practitioners.
    
    www.lastconfernece.com @lastconf #lastconf
  - Jan 2008 - Present
    Director / Evaluator.com.au
    
    Consulting business that helps you understand how to improve your project and technology performance.
  - Jul 2012 - Aug 2012
    Program Manager, Customer Advocacy / Telstra
    
    Responsible for
    - Coaching executives and general management on the meaning and application of customer advocacy, lean and agile practices.
    - Portfolio management across Telstra Operations Customer Advocacy program; PMO across both capital and operational programmes targeting improved customer experiences
    - Integrating multiple PMOs across Operation’s lines of business into one Advocacy Portfolio.
    - Hands on program coaching on top 6 priority Customer Advocacy programs.
  - Jul 2011 - Jul 2012
    Head of Project Management & Assurance / Swinburne University of Technology
    
    In this role I had three main responsibilities:
    
    I managed the project delivery capability at Swinburne's IT department. This includes project managers, business analysts, quality analysts and testers.
    
    I managed the IT project Portfolio and PMO.
    
    I was also engaged in working with business partners to the IT department to help increase overall project and product delivery capability.
  - Jul 2011 - Jun 2012
    Occasional Agile Trainer @ Telstra / Accenture
    
    Participating in the agile adoption at Australia's largest telco.
  - Oct 2010 - Jun 2011
    Consultant / Business Analysts Pty Ltd
    
    I worked with organisations to increase their project capability through systematic improvements to process, systems and tools. I also coach with people on BA and PM techniques and methods and also help out on projects at a practical level.
  - May 2008 - Nov 2010
    Program Manager / Workcover NSW
    
    Managing strategic program updating business models, replacing legacy IT systems with both in house and vendor delivered solutions, and implementing Scrum along the way.
  - Mar 2008 - Jul 2010
    Lecturer / Melbourne Institute of Technology
    
    Lecturer in Project Management to Masters degree students.
  - Apr 2008 - May 2008
    Consultant / St George Bank
    
    Project recovery and strategy work.
  - Jul 2005 - Feb 2008
    Project Consultant / OptimiseIT
    
    Projects I worked on at ANZ Mortgages included;
    - Strategic planning
    - Major IT programs
    - Enhance corporate web site (sales channels)
    - Six Sigma projects
    - Training and coaching staff
  - Jul 2005 - Dec 2007
    Project Consultant / ANZ
    
    Working via OptimiseIT
  - Dec 2006 - Apr 2007
    Project Manager / Telstra Business
    
    Managing new products to launch for Testra's business customers.
  - Sept 2003 - Feb 2007
    Director / erina legal
    
    Erina Legal is a law firm based upon the Central Coast of NSW.
    
    The practice areas are Family Law, Property Law (especially conveyancing), Business Law, and Wills and Estates.
  - Dec 1997 - 2005
    Various roles / Optus
    
    Project Manager, Manager of the Business Process Improvement (BPR) Team, Business Analyst, IT Management, Technical support.
    
    For me, Optus was several years of working with great people on cool projects.
  Education
  - 2005 - 2007
    
    RMIT University
    
    Masters in Project Management
  - 1990 - 1994
    
    University of Newcastle
    
    Bachelor in Business
    Activities: Student Union member, Editor of campus newspaper, BBQ organiser, ahh good times...
  - 1983 - 1988
    
    Henry Kendall High School
  Additional Information
  - Websites:
    
    Blog, Company Website, Personal Website
Posts

Posts

Feed
- Your MVP is all Bull
  
  Nov 25, 15
  
  When I need some inspiration, I often start on the journey searching for it by looking at some of the works of my favourite artists, one being Marc Chagall, another Helen Norton and of course Pablo Picasso (I also love his quotes as they resonate so well with me!).
  One of these explorations brought me to think about artistic merit in product design and how we need to think about and approach what we are designing in agile terms known as the MVP (Minimum Viable Product) in collaboration with the product owner.
  I believe at minimum the key characteristics is that the MVP must at least be:
  1.    Valuable to the product owner and the end-clients with a real business purpose and utility and not just be another “nice thing”.
  2.    Do-able practicable with realistic delivery in line with the team capability in a short timeframe (weeks not months).
  3.    Affordably satisfy a tangible ROI in a no frills way and be able to evolve from an initial base delivery to create more and more incremental value else it should be "extincted" quickly.
  With that in mind my teams and product owners often ask how they should approach the definition of the MVP and in particular "what it should look like". Well, that's not an easy answer at all because the product concept may only exist initially as an "idea" that needs stimulation for manifestation.
  Before starting the stimulation process we need to agree that we need to satisfy the above MVP key characteristics, and then enter into activities that will lead to the products exhibiting "artistic merit" by stimulating team creativity and innovation so that we can craft the MVP from virtually nothing into what it is to become.
  For this not to just be a "woolly generic statement", we need to refer to some examples to make it easy for the team to generate inspirational emergent ideas that will lead to "what this would look like" in real life.
  So for this I like to use Pablo Picassos "Bulls" as inspiration and illustration, by talking the image through with the team and the product owners. This particular artwork is a very powerful creative instrument that often amazes with how quickly the teams "gets it" to start talking about what the MVP should look like.
  This image quickly lands the team to distil the product design framework to its most minimal and simple essence, exactly as Picasso does with his bull!
  Although Picasso has followed the process to "de-construct" the bull from the most complex to its mere essence, one can approach it from both sites as either de-compositional or/and re-constitutional points of view.
  Its for me the perfect illustration of how to achieve the ultimate MVP of the Bull.
  
  To sum up; To land on a great MVP the team needs to process some iterative hard tack inspiration interspersed with interaction and collaboration on de-and re-construction of the product as a Bull!
  And now in the spirit of artistic inspiration some whimsical imagery from Helen Norton with "The Bull of Heaven Descending"
  
  (Note. The bull sculpture in the header is available for the serious collector - buy from here)
- Wet Scrum
  
  Jul 31, 15
  Guest post
  Many thanks to Gurpreet Singh for allowing us to re-post this article about what he calls "Wet Scrum". He will be in Australia in mid-September as a session leader at LAST Conference.
  Workshop with Gurpreet at your company…
  Gurpreet will be available to run a 3 hour workshop with your team, in the days around LAST. If you would like to know more about this opportunity, take a look at Gurpreet's info sheet (PDF)
  Wet Scrum
  By Gurpreet Singh
  Many companies tag themselves "Agile." Agile is the latest Methodology to execute software development projects. Agile has a variety: like Scrum, eXtreme Programming (XP), Rational Unified Process (RUP), etc. Scrum is the most commonly followed these days. Generally, organizations use a blended version to suit their needs, which are confined within their environmental constraints (EEF/OPA, or enterprise environmental factors/organizational process assets).
  So, why are companies moving to Agile?
  
  Let's recap the Agile Manifesto to answer this question:
  Individuals and interactions over processes and tools
  Working software over comprehensive documentation
  Customer collaboration over contract negotiation
  Responding to change over following a plan
  Agile empowers the client with the flexibility to change, as the entire process is iterative and the client is kept in the loop with each sprint's progress. Also, the team plans and commits for work for each sprint and works together to complete the commitment.
  
  This way, it is a win-win scenario for each side:
  The client is updated in real time about the status of the project/product, and the client has the freedom to change the requirements.
  The team is like a small military Alpha unit (five to nine members) working in short progressions (sprints).
  The hard truth
  Hmm . . . this was the theory. Life, though, is not about black and white; there are grey areas everywhere.
  
  It is easier to "do Agile" than to "be Agile." Agile demands a certain discipline to get the right results.
  Do you timebox your meetings?
  Are you a silent listener during the meetings?
  Is the product owner or ScrumMaster the only person who talks?
  Is the PO/SM "pushing" the work to you?
  Does your PO commit during the sprint planning without seeking team input?
  Are you forced to give XYZ points to ABC story?
  Are you not "open" in the retrospectives for fear that what you say will backfire?
  Are you forced to take on new stories during the sprint that will negatively affect the already committed deliverables?
  Do you never discuss blockers in the daily Scrum meeting, despite the fact they exist?
  Do you expect/wish that the PO/SM would micromanage so you only have to "work"?
  Do you believe the carrot-and-stick method of management is essential?
  These scenarios are just few highlights; the possible list is endless. They show that you are "doing Agile" (for the sake of doing it), but you are not "being Agile," as you don't know the real importance of Agile practices and deliverables.
  
  You may be an Agile puppet run by someone else following Waterfall. This kind of Scrum is notoriously known as "Water-Scrum-Fall."
  
  I would like to coin a new term for this method: "Wet Scrum."
  
  Scrum gets "wet" by following the practices of Waterfall. People use Scrum selectively, depending upon context and ease. However, it is very difficult (nearly impossible) to achieve the spirit of Agile by doing this.
  How Wet Scrum Works!
  Clients need the following:
  More human touch
  Manageable work organized in short sprints rather than trying to manage the entire project/product as one entity
  Real-time updates about work completed
  The power to change the requirements
  High-quality results
  These deliverables are produced by Scrum, in theory. However, no way of working can ensure the success of a project or product unless the team is disciplined and focused on making it a success. (We will discuss this point further at a later stage.)
  
  Clients are fascinated about using Scrum to address the needs listed above. This creates pressure on the senior management of XYZ Company to shift to Scrum. And this creates a cascading pressure on middle management, junior management, and finally on our teams to be Agile. The team doesn't necessarily have an awareness of the Agile values, but they need to be Agile, as this is a clear mandate of senior management and the voice of the client. They start holding daily Scrum, sprint planning, and retrospective meetings without a clear vision of the end goals or their purpose. The burn-downs literally burn down these Wet Scrum teams. Sizing seems alien to them. They aren't sure about the roles of the product owner and the ScrumMaster. They believe they are self-organized, but they need some manager to manage their work.
  
  In a nutshell, they are "Agile" as being demanded by the client (or management); however, they are miles away from being Agile. This is a sad state and is cruel for the team. Gradually, the team will feel that the meetings are senseless. For example, if they are regularly taking on more stories during the sprints, the sprint planning meetings lose their purpose and become a waste of time. Similarly, if the daily stand-ups last for 30 minutes, this is a clear waste of the time for the entire team (30 minutes times X number of team members daily).
  
  In the long run, the team will start burning out. They will lose focus and motivation, and the product will fall from creative mode to survival mode.
  
  And . . . everybody will blame Agile (read: Scrum) for this failure. However, if the people involved do not want to make the product/project a successful one, it will be a sure failure no matter which method you use.
  Closing note
  Competition is high, so companies try everything to make new customers and to sustain the old ones as long as possible. This includes shifting to newer formats such as Scrum, Kanban, etc. However, this kills the creativity, innovation, vision, human spirit, and motivation of the people who actually create the product or execute the project.
  
  Agile was born to empower people and their communication, and this is lost in Wet Scrum.
  
  Wake up now! - See more at: https://www.scrumalliance.org/community/articles/2013/december/wet-scrum
- The invisible gorilla
  
  Jun 29, 15
  By Venky Krishnamurthy
  Recently I read about NASA’s Columbia mission disaster. As many of us remember, on Feb. 1, 2003, space shuttle Columbia broke up as it returned to Earth, killing the seven astronauts on board.
  
  The Columbia Accident Investigation Board (CAIB) concluded the following in their final investigation report
  Cultural traits and organizational practices detrimental to safety were allowed to develop,” the board wrote, citing “reliance on past success as a substitute for sound engineering practices” and “organizational barriers that prevented effective communication of critical safety information” among the problems found.
  
  As per the report, some of the engineers discussed the dangers of foam falling apart with the senior management. However, the management simply ignored them and didn’t attempt to find a fix, which is a reflection of deep cultural issues at NASA. The management didn’t think this was a major problem. The report also claims that management didn’t bother to take action because of a view that the problem was unfixable, based on past experience.
  The reason I am referencing this article here is because I see a lot of similarities between this case study and the way enterprises typically operate. When the team members see a risk in the project and reports to the management, either the issue is ignored, or the team member is termed as a trouble maker.
  From the leadership point of view, the takeaways for us are:
  Give serious attention to every risk or issue raised by the team members. Don't ignore any even if it sounds stupid
  Don’t let your past experiences stop you from finding and trying new solutions.
  In large enterprises and complex programs, issues crop up all the time. Leaders could become immune to listening to problems and start focusing only on larger issues. In fact, this pattern of giving too much importance to bigger issues and ignoring the smaller ones seem to cause major disasters in history.
  
  As per the discipline of complexity science, many a times the weak signals carry very powerful and important information. We tend to ignore them and focus only on strong signals, thus causing major problems.
  
  The experiment from psychologists, “The monkey business” illusion is a classic example of how we miss out on the “Gorillas” amidst chasing key goals.
  
  The Columbia disaster could have been averted if the management listened to engineers and attempted some steps to fix the foam issue.
  Similarly, major challenges in the project schedule, scope or budget could be averted if the management listens to the weak signals. That is, small risks hidden from the "big visible charts".
  Before I conclude, let me ask you two questions.
  Think about your current project, visualize your project risk board"
  Have you missed seeing any “gorillas”?
  Have you recently ignored any issue raised by a "junior" team member?
  KEEPING TABS - TABAR'S NEWSLETTER
  If you want links to interesting reading and notifications about upcoming events in the Melbourne and Australian lean/agile/workplace change community, please signup here.
- Who comes to LAST Conference?
  
  Jun 10, 15
  
  By Ed Wong
  A version of this post first appeared on Ed Wong's personal blog. LAST Conference is part of Tabar's event series, that also include 1st Conf for new agilists and Spark the Change (formerly Dare Festival)
  I run an event with Craig Brown called LAST Conference. It's happening for the 4th time on 18 September 2015. In 2014, I was pleasantly surprised that the Software Development Today blog rated us #20 in the Top 50 agile conferences.
  It's a meetup on steroids
  Of the various descriptions there are about the event, I like "It's a meetup on steroids", the best. It's designed for people who have a bit of experience with agile (I run an event called 1st Conf for people who have less experience). We have a whole day of workshops, talks, lightning talks, retrospectives etc. We deliberately have up to 7 concurrent sessions, to keep things exciting and we keep it really affordable, too.
  Who comes?
  In the lead up to this year's event, I was doing some analysis of who comes along so I thought I'd share. Look ma, I did a pie chart! Click the preview above for a larger version.
  Not unsurprisingly, people who fit into a manager role, make up the greatest proportion of participants, followed closely by Business Analysts. The types of job title that made it into the Manager bucket were "Business Solutions Manager" or "Practice Manager".
  It's good to see that there is a reasonably diverse spread of roles and it's really good to see that Developers are about one fifth of the cohort, there's a few Architects and a good few QA people. I would like more UX folk to come along…we've got a couple of UX sessions in the pipeline this year.
  18 September 2015
  We've run the event in the darkest days of Melbourne Winter, up until now. This year, we're going to be in Spring! In order to make use of Swinburne Uni's brand-new Advanced Manufacturing Design Centre (AMDC), we have moved away from their crowded winter term and instead will be on 18 September 2015. We will be opening registration in the coming days (signup to the mailing list to be the first to know), and you can still submit a session idea, over on the LAST Conference website.
  Headline sponsors - elabor8
  Sponsorship from companies keeps the event affordable. elabor8 have returned as headline sponsors this year. If you'd like to join them, then please get in touch.
- Zappos and the "no bosses" approach
  
  May 18, 15
  By Venky Krishnamurthy
  
  Zappos CEO, Tony Hsieh
  
  After reading this article from the Washington Post, I felt saddened to see many employees leaving Zappos. Zappos might have a point to prove that these employees are incapable of adjusting to their new “way of working”.
  I think it is dangerous for Zappos to survive in the long run. Here are two reasons:
  The diversity of thinking: success of any team, group or an enterprise depends on its encouragement to the diversity of thinking. If everyone in the organization is forced to think in a certain way, one will end up breeding “Yes” masters and thus killing creativity, innovation.
  
  As one could see, Zappos management is forcing people to work in certain way and non-aligned workers are booted out but in a diplomatic fashion. I agree that the Holacracy way of working can benefit the organization, however Zappos is killing the a foundation that Holacracy promotes; that is, respecting people and their opinions.
  
  As per one of the research, employees perform at their peak potential when their individuality is respected and protected.
  
  Organizations flourish and succeed with inclusive policies rather than exclusive ones.
  
  Brain drain: A bigger issue is the impact of brain drain on the organization. There are rumors floating around that many employees who opted to quit Zappos have set up new startups. The three months salary is good enough for many entrepreneurial people to use it as seed funding to setup their own business. Loss of such talented people is a great tragedy for the company.
  Sometimes, I also feel that many organizations come up with fancy ideas/strategies as part of laying off people as well.
  What do you think about Zappos decision ?
  For those of you interested in this topic, the Melbourne Agile and Scrum Meetup group will be discussing Self Organisation and Holacracy at its next Meetup on 27 May 2015.
  Keeping Tabs - Tabar's Newsletter
  If you want links to interesting reading and notifications about upcoming events in (mainly) Melbourne and Australian community, please signup here.
- LeSS is more in Australia
  
  Mar 26, 15
  By Anton Rossouw.
  It was great to have Bas Vodde in Melbourne from 24 - 26 February 2015 to bring the first Certified LeSS Practitioner course to Australia. Its been several months in the making following a plot with Bas to visit Australia, crafted over great Japanese barbeque and Sake at Clarke Quay in Singapore. The Melbourne location was also good enticement to exploring Tasmanian Whisky in pursuit of the most excellent in the world! With that trigger discussion still clear in my memory I started day 1 of the 3 day LeSS training with Bas and 15 others at our partner organisation Elabor8’s training room.
  
  My initial expectation of LeSS was that there could not be that much more to scaling Scrum that we weren’t already intuitively doing in some way, so anything new under the sun? I was very wrong! It dawned quickly that what Bas presented was taking Scrum itself to a whole new level of excellence! What I learned was somewhat of a surprise because “LeSS lets you do better Scrum” too. It’s not only about scaling teams and large product delivery but also at the same time amplifying the practical goodness at the heart of Scrum i.e. the agile stuff that really works. The course also brings many new agile aspects to the fore while also remaining simple, compact and focused. The particularly powerful concepts that resonated deeply with me were:
  Steps and strategies to evolve Agile scaling into the wider organisational context in a low risk productivity enhancing way
  Building cross functional feature teams across the organisation while driving understanding and contribution to the business domain
  Applying organisational, product and process improvement from running retrospectives (overall) at scale emphasising that learning is at the core of LeSS
  Specific roles for management steers them in support of teams and not control of people
  Managing the one product backlog and driving Done and Un-Done work to get to extended enterprise level “totally Done”
  Sincronisation of sprint time boxes into the same calendar cycle
  What do we do when the product requires more than 8 teams i.e. going “Less Huge”
  Two step sprint planning to cover enterprise level and team level planning for delivery
  Managing the backlog according to dynamic requirements areas that reflect the enterprise contexts
  Moving the teams and the organisation structure to customer and whole product focus
  Applying Less principles underpinned by systems thinking that further enhance and support better Scrum
  Moving away from project focus to continuous emergent Inspect and Adapt driven delivery
  Moving from component teams to feature teams using a planned strategy based on a long term adoption map
  Sometimes temporary fake product owners are valuable and needed!
  Using and authority matrix to differentiate responsibilities for product owners, management and teams
  The simplicity at the core of LeSS will de-complicate the organisational structure over the longer term and drive efficiency
  In summary LeSS is not only about how to scale Scrum into a transforming organisation but also how to do better Scrum at every level. This emerged strongly from the stories throughout the training informed by Bas’s years of experience and deep thinking on practical application of LeSS.
  Indeed a great start to more LeSS being done in Australia! I am convinced that LeSS.works as what happened to the relatively recent and unknown Tasmanian Whisky is also earmarked to become the de-facto reference to Scaling Agile excellence in the world. Go LeSS!
  
  Bas and Venky
- Personal Kanban FTW
  
  Mar 24, 15
  
  It was a lot of fun presenting on Kanban at 1stConf last week, it was a popular session and special thanks to Neil and Martin for helping make it fun.
  In my talk I gave out Personal Kanban boards and I've had a lot of fun using them myself, here is the design, inspired by Sandy at Nomad8.
  
  I've found myself wanting to cary around the printed kanban with me and I've discovered a relatively easy way:
  
  I rolled up a blank A4 piece of paper and used sticky tape to turn it into a tube for the board to slide into. As a bonus the sticky notes fit in the tube along with sharpie and bluetac. I need plenty of bluetac to flatten out the board after storage.
  Hope you enjoy you Personal Kanban boards! If you want the slides from my talk get in touch below.
  Enter your email * I'll send you an email with the slides and let you know about any upcoming Kanban presentations or training I'm doing.
  Thanks, I'll email you the PDF.
  You can also follow me on twitter @agileben or email at ben.hogan@tabar.com.au
  
  Upcoming Training
  I'm doing a 1 or 2 day Intro to Kanban on the 16th / 17th April in Melbourne. If you or someone you know would like to attend please check it out.
- My first brush with Large-Scale Scrum (LeSS)
  
  Feb 12, 15
  
  Venkatesh Krishnamurthy
  I had my first opportunity to practice LeSS in 2006. While I was with Valtech in Bangalore, Craig Larman, who was, the chief scientist was already in the process of forming LeSS ideas.
  Being a Scrum Master at that time, I had the opportunity to work with Craig closely and watch him implement some of the LeSS principles, tech practices and structuring the organization to be nimble.
  Being a computer scientist, I got impressed with the technical practices and started making my hands dirty in integrating various tools, rolling out configuration management practices and setting up continuous delivery/integration and deployment environments. I was able to capture some of these experiences in an article I published in 2006 for Agile Journal. This is accessible here. It was aptly titled, "Tools integration in distributed environment".
  Another pet project that I worked with Craig Larman was building something called "Virtual Lava Lamp".
  
  Virtual Lava Lamp
  As one could see from the screen shot above, the Lava Lamp was integrated with the Continuous integration environment(Cruise Control + SV) and build results used to trigger this lava lamp. Green indicates all good and red used to encourage the developers to fix the build. Craig and I built this on a simple X386 machine, which was super low cost.
  All the good technical practices are covered as part of LeSS framework and under the Technical Excellence subsection as shown below:
- LeSS: Scaling Sweet Spot
  
  Jan 22, 15
  
  By Venkatesh Krishnamurthy.
  Read the first part of this series about Large Scale Scrum
  There are several frameworks, ideas and methods available for scaling Agile projects. Many are either too prescriptive detailing out practices making it too narrowly focused with no wiggle room. The prescriptive, highly defined process destroys the principles of empirical process control.
  There are others which are purely principles based pushing the onus on users to worry about the practices.
  The secret lies in balancing the principles and the practices. This is where Large Scale Scrum (LeSS) captures the sweet spot.
  
  LeSS achieves the same balance as Scrum, for larger product groups. It adds a bit more concrete structure to Scrum, whose purpose is to maintain transparency and emphasize the inspect-adapt cycle so that groups can continuously improve their own ways of working. LeSS consciously leaves the space for users to create context dependent practices.
  Find out more about LeSS training in Melbourne in February 2015. This is the first LeSS certification training in the ANZ region.
- What is LeSS (Large Scale Scrum) ?
  
  Jan 13, 15
  
  By Venkatesh Krishnamurthy
  In 2015, we are going to introduce Large Scale Scrum (LeSS) to an Australian audience. We think there are many who will be interested to hear about what LeSS is all about. How can it benefit large scale Agile projects? What are the principles driving LeSS? How can I be LeSS certified?
  My intention is to share knowledge about LeSS and at the same time, answer the above questions and beyond. In this series of articles, you will be able to gain an understanding of LeSS and LeSS huge frameworks.
  Why LeSS?
  Let me begin with "What is Large Scale Scrum (LeSS)? Essentially, LeSS is Scrum being applied to many teams working on a product development.
  As we know, Scrum is one of the most popular methods in the software development. Its popularity is due to its simplicity and powerful empirical process control. However, while multiple teams working on a product development apply Scrum, they need some additional guidance for improved collaboration and coordination. This is where Large Scale Scrum sits.
  Since LeSS is based on Scrum, the learning curve in adopting this framework is minimal. Personally, I have used LeSS on a large scale development with >100 people with no additional training on this framework.
  LeSS Principles and Themes
  LeSS is fundamentally based on Scrum, and in addition, it has principles/ideas based on Queuing Theory, Systems Thinking, Lean Thinking, Empirical process control.
  I will delve a bit deeper into the backlog grooming and other practices in the upcoming articles.
  Read the Part 2 of this series "LeSS: Scaling Sweet Spot"
  Find out about the upcoming LeSS course in Melbourne
- Don't shoot the elephant...
  
  Oct 16, 14
  
  By Venkatesh Krishnamurthy
  Recently I came across this fascinating story by Orwell about shooting an elephant.
  Orwell, who was an English officer in Burma during 1920's, was tasked to find the killer elephant. As he continues searching, finally finds the elephant in a field calmly eating it's food. However, the crowd around Orwell starts jeering him to shoot the elephant and even more after seeing his gun.
  As Orwell describes in his story,
  Despite Orwell’s aversion to shooting the elephant, he becomes suddenly aware that he will lose face and be humiliated if he does not shoot it. He, therefore, shoots the elephant.
  You might be wondering, why I am sharing this story here... but wait I believe there is a huge meaning and a management lesson to be learnt from this story.
  In the above story, even though Orwell wasn't interested in shooting and killing an elephant, he was under social pressure. Orwell being in an authoritative position wanted to satisfy the crowd's hunger to look good and at the same time, he didn't want to look weak in front of them. Do you see what I see?
  I see this behavioral pattern in everyday life at work and in other social situation as well.
  For example, consider the setting where one of your leaders is chairing a meeting with team members. One of the naughty team member asks a sensitive question about the unnecessary money being spent in furnishing the office when the company is struggling with cash flow.
  What happens now? The room goes silent, and everyone would be looking at the leader to see the response. Now the ball is in leader's court, and obviously the leader has to defend. In the mean time, if the leader has a command/control leadership style, he/she cannot remain silent and show as weak. This leader now wants to demonstrate the strength in front of the team. That’s when all the insecure leaders shoot the elephant.
  Many leaders shoot the elephant as a warning to others and sometimes just to satisfy their ego.
  To conclude, I would say that we all come across social situations where we are expected to act in a certain way. The people around us whether our spouse and family, peers or team members wait to see our response. It is important to be mindful of the situation in a social setting without getting into social pressure.
  In the Orwell's story, the "Mahoot" or the elephant trainer could have been called to take the elephant back to the forest rather than unnecessarily killing the elephant to satisfy crowd's expectation.
  Have you come across situations where your leaders have shot the elephant ?
- What is common between Agile and FengShui ?
  
  Oct 08, 14
  
  By Venkatesh Krishnamurthy
  I know this is a tricky question if someone asks "What is common between Agile and Fengshui?" . Not an easy answer ah?
  Let me give out the answer, both Agile and Fengshui has a lot of believers and followers. The followers have such a tremendous blind faith that they don't question and follow the rituals to the last letter.
  For example, I have seen Feng Shui followers setting up Aquariums, buying gold fishes, lighting scented candles to attract wealth/abundance. Whether it works, don't know.
  I am seeing the same trend in Agile followers as well. If there are challenges in software delivery, stakeholders are asking the teams to just "practice" Agile and many a times some popular models like Spotify, SAFe or DAD.
  Many a times, just ignoring all the noise and just applying some common sense could solve many challenges.
  Are you a follower surrounded with too much of noise? Do you think ignoring this noise helps in your context?
- Agile? Ask "why" first!
  
  Aug 18, 14
  I like the word “Agile”. It positively amplifies implied action, energy, and change. It also gets the change sceptics talking (we have always done it, it will not work, we have done it before, its not we us) !
  I also believe Agile is a “strange attractor” ( Chaos Theory) that can be applied in social complex systems as a meme that attracts organisational behaviours towards the point in a basin where “newness” emerges. Emergent newness is uncertain and can be hugely disruptive or greatly beneficial.
  
  Dangerous roller coaster ride !
  
  Caution is in order because Agile transformation can be a roller coaster ride where you must hang on for dear life!
  Before getting on to the roller coaster ask “Why”. Don't get on until solid answers are articulated and a clear destination is envisaged.
  Reasons why not to get on the roller coaster are:
  It's a new and interesting fad not be missed.
  Lots of cool people seem to be doing it and having fun.
  One thing about Agile is that it will change your organisation, so we need to do it for the right reasons and for the better!
  I found many of those right reasons in Stephen Wageners book Adventures in the Sea of Complexity. It explains in a humorous and engaging way what the new Agile world order looks like.
  The story reminds me of one of my all time favourite poems - Lewis Carols The Hunting of the Snark.
  
  Royal Family of the Kingdom of Mismanagement
  
  In the book one meets the rulers and inhabitants of the Kingdom of Mismanagement, a sovereign island nation. They live in denial of the surrounding Sea of Complexity that rages to create chaos in the island. King Schedule and Queen Urgency govern with an iron fist. Their son the fierce Dark Prince of Finance enforces control. A myriad of other characters prop up the Kingdom. You will meet the Crown Prince of Engineering, The Countess of Change, the band of Process Monkeys, Mr Continuous Degradation and the Grumpy Old Men of Influencers .
  The story amplifies the undertones of modern corporate life on to Dave Snowdens Cynefin model, bringing it to life in a way that leads to unexpected emergent praxis. It also amplifies the important element of fun in the workplace as an alternative to simplistic debilitating seriousness.
  
  You will also meet the elephant in the room. They are more common than one may realise!
  
  Elephant in the room !
  
  This book has offered me many poignant answers to “Why Agile?” as it illustrates what needs to change and how it needs to change.
  Get a few copies for your company today and distribute it around. Prep the network for change. Be brave enough for the roller coaster ride but make sure you Inform - Select - Confirm at first.
  Embark on a fun journey for all !
- Mediocre Managers Manifesto
  
  Aug 15, 14
  I have had the privilege over the past 30 years or so to work with many humane, inspiring and energising managers and leaders.
  Since studying Industrial and Organisational Psychology and Computer Science in the early 80's back at university it has always been my hope that management science (with some technology) will foster the development of better managers. However of late I have not seen much evidence of that.
  So in homage to the great leaders that inspired me I decided to create an “anti-” view that can be used to tacitly amplify what “good” leadership looks like as the mirror image i.e. “bad”. As a pattern I used the Manifesto for Agile Software Development (representing those on the good side).
  Reflecting on my past career I must also confess that at times I caught (like a bad cold) some traits from the not-so-great managers I worked with because it seemed a good idea at the time and the accepted “way we do things here”. I now recognise that one should never take on bad behaviours but stand firm and be brave enough to change it, even though it means you may lose your job (yep its not as easy as that especially when its about money).
  After all is said and done to get the “job done”, I always hope that I leave my workspace as happier places where I helped my teams in some way develop and grow to their potential.
  Now for the Mediocre Managers Manifesto for creating Mayhem and leading the organisation up Schitt Creek without a paddle:
  
  We are uncovering strident ways to work by doing it and forcing others to do it. Through these ways we have come to value:
  Command-and-control over agility and self-organisation.
  Passive aggressive conflict over collaboration.
  Arguing the details over working the big picture.
  Being promoted over delivering value.
  Blunt answers over thinking what’s best.
  Information secrecy over transparency.
  Talking incessantly over listening intently.
  That is, while there is most value in the items on the left, there is little value on the right but we will say we do it even though we don’t.
  We follow these principles:
  Me, myself and I as the supreme manager always know best.
  Always blindly follow the bosses’ orders because they know best.
  People are annoying but considered as resources to be consumed and discarded.
  Get the job done at any cost but remain true to yourself by using manipulation, throwing tantrums, and whinging.
  Playing people off against each other is an important and fun game.
  Bantering in a critically logical way will be used to belittle, confuse and disorientate the team, and when that fails because they have better answers, then emotional blackmail must be applied.
  When I don't understand something then it is their fault.
  Vendors and suppliers are important because they are someone to blame when my team stuffs up and I don't want to lose many of my team members in one go.
  With power comes responsibility to weed out clever, considerate and open people. They have no place in this world and must be taught a lesson.
  Apathy must be applied to protect us from commitment.
  We believe in our own rhetoric as enforceable doctrine for everyone else to obey.
  Knowingly withholding acknowledgment and approval motivates people to try harder next time.
  Managers are not paid to foster happiness at work, rather spend their time growing empires and attacking others empires.
  My smartphone is at any one time more interesting than what anyone is trying to say in any meeting, except if it is a bosses meeting.
  In particular don't trust individual workers but specifically not teams because they may over time wield more influence than the manager. Facilitate infighting within teams to reduce their effectiveness.
  The Mediocre Managers Manifesto can be used as an assessment checklist tool for managers “where the shoe fits”. If only a couple items apply then there is hope and behaviours can easily be ameliorated, but if most items apply then major therapy and years of coaching would be required to become a “normal” manager again.
  To further explore the "bad" side of management one of the best books about it is by Barbara Kellerman. Believe that good management is possible. Inside every bad manager maybe there is a great leader trying to get out!
- Happy Remote Workers
  
  Aug 15, 14
  
  We are of the firm belief that the happiness quotient of remote workers can be improved dramatically. We know that the people in development centres and outsourced offices in places like Bangalore, Ho Chi Minh City and Manila will grasp at any opportunity to contribute more to projects and teams at "head-office" in Melbourne or Sydney.
  A little help and support to engage them into the fold will go a long way. We think we have a good innovative part of the answer that can help overcome the tyranny of distance!
  Our Double Robotics remote worker avatar has now been alive for three weeks. Her name is Melly, and her purpose is to help remote workers work in happier ways by being their representative and avatar where they are needed.
  It was easy to bring her into life with the help of an iPad or two and a WiFi and 4G internet connection.
  She is a delight! Very friendly and agile, always available when you need her in meetings or just for a quick chat. She gets around the office quite nimbly and can manoeuvre herself almost everywhere, but she is a bit wary of power cables and stairs.
  She has really good hearing and a commanding voice that can effectively be used to make her presence known. Meet Melly in action.
  
  She is a key ambassador of our Happy Melly Australasia remote worker happiness product, and we will be pleased to introduce her to your office and your remote workers, be it at a school, remote mine site, head-office or satellite office. Contact us today for a chat with Melly!
- The Network is the System
  
  Sep 03, 13
  
  Our tribal business model is based on the anthropology and sociology of tribes as networks.
  Therefore we hold Network Theory as well as Complex Systems Theory dear to our hearts in our consulting practice, and often offer the combination as a great explanation of how leaders could understand the true holistic nature of organisational structure, innovation incubation, opportunity discovery and directional flux influence for strategic direction setting. It also works well to model the complexity of business groups such as programs and projects.
  One of our most valuable primary paradigms towards understanding enterprise dynamics is to view organisations as a Complex Adaptive Systems that comprise a range of connected and linked nodes (agents) represented as a Network, as opposed to use the traditional simplistic hierarchical representation.
  However, hierarchy remains a valid representation because the effect of hierarchy on our thinking can be used as a visualisation and sense-making cue to overlay on to the organisation as a network. When that is done, very different perspectives emerge from the visualisation particularly uncovering the nodes where true leadership and influence reside. This leadership and influence to best stimulate adaptation and innovation in organisations is most often not located in the traditional executive management structures as most people expect, but within the organisation in unexpected nodes.
  Therefore an understanding of networks and how they operate in the real world is a very important contributor toward facilitating effective future strategies and innovative change. It is often better to harness the power of the network than to utilise the hierarchy.
  
  A great way to start understanding the power of network visualisation, is to start with one’s own LinkedIn profile “network” which can be graphically visualised by a tool developed by the LinkedIn Labs. Our brains are great at pattern recognition and networks are great at offering patters for our brain to play with. As an example the clusters in my network are related to the various professions, technologies, industries and organisations that I have been involved in during my career, including a recently connected small network going back thirty years to the friends that I left school with and went to University with. I can with this visualisation explore complex connectivity that I was previously unaware of.
  A great lecture on the importance of networks and what it can tell us (it explains the world!) can be found on the Santa Fe Institutes' (The best source for Complexity Science) YouTube channel - presented by Prof. Mark Newman - one of my favourites clips that I often re-visit.
- Scrum is Anti-Fragile
  
  Aug 21, 13
  Some months back I read Nicholas Nassim Taleb’s latest epic tome “Anti-Fragile - Things that gain from disorder” .
  I bought the book because I loved his previous two books “Fooled By Randomness” and “The Black Swan”. And his mini poetic diversion “The Bed of Procrustes” is a great diversional romp into the philosophical space.
  
  Image - Amazon
  
  I have no doubt that he is a brilliant thinker and should be placed close to the top of the Pioneers list of the worlds most influential people (he is not listed yet).
  The other person I see as a peer is Dave Snowden. I would love to see a serious philosophical debate between the two of them but suspect it will start in the sphere of massive disagreement and end where they eventually agree on everything !
  Diversions aside, I found the book and the concept of Anti-Fragile interesting but challenging.
  Perhaps my brain is fragile when it comes to new hard-hitting conceptual arguments like this. I could at first not warm my mind to what Anti-Fragile could mean, and the closest I got was perhaps the words “toughness”, "agility", “resilience", “robustness”, "adaptation" and "evolution" which I was well acquainted with.
  I discarded most of those words except Resilience because the other words did not carry enough multi layered meaning to approach Anti-Fragility with.
  Resilience also made most sense because I read Andrew Zolli and Ann Marie Healy's book "Resilience - Why Things Bounce Back" directly before I read Anti-Fragile.
  
  Image - Amazon
  
  I then toyed with trying to understand the antithesis of Anti-Fragile and came with “Anti-Agile” and also for some reason thought of the word “Government”.
  As I plowed through the pages it became clear that there was no readily available synonym or close-fit word to describe what Anti-Fragile means. So here follows my summary in the terms of Complex Systems (the living type):
  It is a particular property of a Complex System as well as a transitionary condition of becoming.
  It is the ability of a Complex System to increase its fitness and become stronger the more it is challenged, exercised and too some extent damaged.
  The Complex System can survive a lot of damage and abuse due to impacts from conflicts emerging from the environment it is in, from within, and encountered by other Complex Systems in the competive space.
  It is a learning COmplex System that is emotionally charged and energises, and best flourishes when pressure is applied to it.
  Reflecting on our Agility, Innovation and Sustainability practice points of view I could not quite understand how Anti-Fragile concepts can be integrated and what we could learn from it, and left it at that in a puzzled state.
  Then one night when watching TV, some nature program documentary again, it struck me !
  Waterfall projects are Fragile and Scrum projects are Anti-Fragile.
  I think the seeds of the emergent thoughts were sown when I spoke to a colleague about Takeuchi and Nonakas' 1986 HBR paper "The New New Product Development Game" (worth a read for some deep insights into Agility) where they explained the difference between an Agile approach and Fragile approach (not their words) as the difference between a rugby team moving forward and gaining ground over a large field as a unit even while being attacked by the opposition, and a relay race where one runner at a time passes the baton on a set track to the next runner, and if one runner drops the baton or stumbles then the race is lost.
  A relay team is thus a more fragile system than a scrum team.
  So Scrum from an Agile sense as well a rugby team is Anti-Fragile because:
  Its a living system compring human agends who move as a team and not as any single individual.
  It is adaptive, self organising and self re-organising.
  It learns and reforms through iterative engagement.
  The more you exercise it the better its performance becomes.
  This mindset could also be applied on our organisational systems I suspect. I will find out when I hopefully attend the Nassim Taleb and Yaneer Bar-Yam NECSI executive education session later this year.
- Braveheart
  
  Aug 20, 13
  
  I enjoyed the 1995’s semi historic and mostly fictional Epic movie Braveheart starring one of our favourite Autralian actors namely Mel Gibson originally from the Mad Max post apocalyptic smash hit.
  Playing William Wallace he epitomises the inspirational, energetic, passionate and “brave-at-heart” leader who with passionate resolve and action starts a deep movement of change.
  In William Wallace’s case he paves the way for the liberation of Scotland against the tyranny of King Edward “Longshanks” of England. At the end of the movie he is offered to submit to the English King but he remains stalwart with a last cry of “Freedom” that rallies emotions and energy that leads to liberation.
  
  Movie poster : www.imdb.com
  
  The movie also brought notions of what Agile leadership may look like as a response to changing oppressive traditional culture, with focused alignment, surgical change, stealthy guerrilla thinking, quick delivery, rapid learning and finding new ways to attack the problems of the past. So I wondered if I can think of examples of corporate leaders that bravely face systemic and cultural challenges and remain focused to push through to enact an almost impossible transformation to an Agile culture.
  I think one such leader is Partrick Eltridge, the Chief Information Officer of Telstra who embarked a couple of years ago to turn their ICT services towards Agility.
  Telstra is Australia's largest telecommunications services provider as well as a huge consumer of ICT technology and labour. Many Agilists including myself have been watching Telstra's journey to Agility with frankly, a bit of skepticism. After all, how do you get an elephant to pirhouette?
  As CIO he took on the task to transform the IT services divisions to embrace an Agile mindset and practice it at the core of its culture. This was a big challenge because Telstra was commonly considered as a slow moving command-and-control driven dinosaurian like bureaucracy that told their customers what was good for them. The old IT adage ”Nobody ever got fired for buying IBM” did not apply to the Telstra of yesteryear. How wrong I was!
  Telstra has been on an Agile transformation journey initiated in 2010 by the then CIO John McInnerley (now at NBNCO) and implemented by his successor Patrick Eltridge, formerly the CIO of SEEK.
  The change is stark because the Telstra of today is vastly different to the one of the past. It is now infused by Agility that puts customers first. However as with any enterprise change of this nature and complexity, it will take more time to perfect, but it is well on the way to achieving Agility.
  How do I know this ? Because much of the intricacies and learning’s from this journey was presented at the last few Agile Australia conferences where Patrick featured as a prominent thought leader.
  The 2013 Agile Australia conference offered us updates on the latest Telstra insights where Patrick contributed in an on stage interview. His leadership team (Lalitha Biddulph, Em Campbell-Pretty, and Jenny Wood) also presented inspirational stories about their journey and achievements at Telstra.
  During his interview he articulated his total focus on aligning the IT organisation with the business and their customers, changing to a culture where teams are less fearful of risk taking, and comfortably adapt to changing conditions, and feel empowered to develop their own skills and expertise. This changed the management culture to an embracing style of leadership characterised by collaboration, openness, inclusion, and a diversity of thinking. Management is now less about control and more about leadership that foster collaboration, and trusts their teams to innovate and deliver. The approach is now all about being curious, receptive, a generalist, and ask first what the customer may want, then deliver it.
  The IT press also offered articles on how focuseds Telstra approached the cultural transformation, particularly making way for a no-blame culture that encourages experimentation and learning.
  What I gained from following Patricks and Telstras journey is that if you are really passionate about Agile transformation because you know and trust deep down that it works best, and you are passionate and brave about it and put yourself forward as a leader, then you will change practices, minds and hearts at deep cultural levels which will delight your stakeholders and customers.
  And as a bonus you get the elephant to pirouette!
- The Chief Innovation Officer
  
  Aug 14, 13
  Many organisations today banter the word “Innovation” around somewhere in their vision or mission statements or in their marketing jargon, but rarely is Innovation given any justice in the corporate world.
  In reality and in practice Innovation is a throw away word that’s used frequently in corporate speak to sound cool, but not taken seriously. Other similar lip-service wasted words which should be taken seriously is "Strategy", "Empowerment", "Agility", and phrases like “Customer Focus” and “Our People are our Most Valuable Asset”. This stems from executive teams that manage as a closed shop with a siege mentality.
  I also love the way that one of my favourite cartoon artists, Tom Fishburne, puts it:
  
  But Innovation MUST be taken seriously, and people are our most valuable asset, and we must focus on our customers because together they are our primary sources of Innovation.
  We have examples of highly Innovative companies such as Apple, Ideo and Samsung that take Innovation seriously. How do they do it?
  Innovation is the one “thing” that could generate that one little spark that can be amplified to save a troubled organisation and transform it to flourish in response to the chaos and complexity of modern business dynamics. And Innovation is also a confusing thing because;
  What is Innovation really?
  Who are the Innovators?
  What does an Innovator look like?
  What do we Innovate with?
  How do we make Innovation happen?
  Why not do an innovation perception check and ask 5 managers in your company to talk about Innovation in their workplaces... I have done that and most often than not had 5 different and fairly confused stories. However, as always Wikipedia provides us with a good plausible starting point towards understanding what Innovation can be from a rational, theoretical and practical point of view. Its a good base top start really getting to grips with Innovation, but that in itself is the fun part of the journey. Yes we have alluded to it – we believe Innovation is not a thing but a journey.
  We have based our Innovation transformation model on Complexity Science because we believe that Innovation is an emergent phenomena of a Complex Adaptive System, and should be approached as such using techniques that are aligned to complexity theory.
  We bundled a group of aligned complexity aligned and derived concepts together that explains to innovation as a Constellation of Creativity. The concepts bundled into the model are Infusion, Messyness, Ecosystems, Networks, Evolution and Exaptation, Creation, Discovery, Technology, Processes, People, Communication and Stories, Deductive and Abductive Reasoning, Design Thinking, and Cognitive Psychology.
  Another core concept in our model is that Innovation should have a leader. After all Apple had Steve Jobs who opened them up to be known as one of the worlds leading Innovators. But was Steve Jobs the only or the sole Innovator, or was he only part of an Innovation network?
  I suspect the real Innovators were the people in the organisation that could bring Innovation to bear. So in answer to the question who the Innovators are, we believe it it is all of us. Every one of us has the capability to Innovate. Its in our DNA as creative inventive survival driven organisms.
  But an innovation leader is still required to help unlock the potential in each of us. The task of this leader is to infuse Innovation into the fabrik of the organisation, and to be Innovative in itself towards creating the conditions for Innovation to emerge from the organisation. We must not allow one small Innovation to be missed because it could have been the "one" to change it all for the better.
  If this person was to be given a standard organisation title, they would be called the CIO - Chief Innovation Officer. The job of the CIO is to declare the company as "Open for Innovation".
- Lets make Melly Shum Happy!
  
  Aug 13, 13
  I met Melly Shum some years back, around 1991 as far I can remember, on a cold, damp and windy morning in the industrial city of Rotterdam.
  I came around the corner of Witte de Withstraat into Boomgaardstraat, and almost walked into her. When I glanced at her she responded with a faint smile a bit like a modern day Mona Lisa, and a friendly one at that. She was sitting seemingly comfortable and confident at where she works, one hand familiarly rested on an accountants calculator.
  A neat and organised workplace, lack of clutter, with professionalism and poise.
  Who was she?
  And what kind of job does she do?
  What inspires her?
  What does she aspire to?
  What is her future?
  What does she want to achieve?
  Then a feeling of dread flowed over me-because I glanced to the right of her and noticed that She Hates Her Job ! What a shame, what a waste! She probably spends at least 8 hours of her work day, week by week and year in year out hating every hour. My only hope for her is that the hours she spends away from work at least she loves.
  I met Melly Schum in an artwork by Ken Lum. It looks like your typical advertising poster – just more striking because there is no glitz or glamour.
  
  Sculpture International Rotterdam - photography: Toni Burgering
  
  Maybe Ken Lum as artist, which I believe has astute observation powers and compassion for humankind, was commenting on the industrialisation and de-humanisation of our institutions and organisations, and used this striking advertising imagery to tell us the story of the modern workplace.
  That is the story of dominant power creating cultural deserts of machine-like workplaces with soft organic living beings substituting oil, steel, heat and steam. Machines can be built, tuned, manipulated, and broken and discarded when they have served their purpose. What resonates is that the many metaphors of business today reminds of optimised machine like efficiency from the Industrial age and the world wars where machines were used to affect massive destructive power.
  Well humans aren’t machine parts, they are complex organisms with emotions, consciousness, self awareness and longing for better futures. I went away with a sense of frustration, thinking about how the "system" can be changed, and if we realistically can have energised, enthusiastic, inspired and happy people in workplaces. People that love their jobs. People that work in places where Profits are not put before People.
  Jurgen Appelo, a leading thinker in complexity and business dynamics also met Melly Schum, and decided to do something about it. He created a movement for change, a network of energetic, like-minded but diverse business people across the world that together work towards changing the world of work for the better.
  Jurgen called this the Happy Melly Network.
  We are proud to be part of the Happy Melly network. We believe that it is good business to have happy people work in our companies. We believe that the workplace of the future will not be described as machines, but as living organisms where value is constantly created by people that like what they do.
  We will work hard to create healthy sustainable business ecosystems that will bring about the necessary change. We will help, and in turn be helped by inspired executives and managers in forward thinking organisations to ensure that all those Malcomes and Mellys everywhere love their jobs. We love this job, and its good business!

Craig Brown

LAST Conference is widely regarded and commented as one of the best industry conferences in the world.

Despite all this, we get some complaints.

This year we are going to try to address the pain.

Use a photo on your online profiles at work. Here is why.

Yeah, but no.

Tips for a good profile pic.

Enter the Frameworks for Agile in-the-large

The way forward

Conclusion

References

How would I describe a Product Owner?

Product Owner description

Microservices: An Accessible Overview

Guest post

Workshop with Gurpreet at your company…

Wet Scrum

So, why are companies moving to Agile?Let's recap the Agile Manifesto to answer this question:

The hard truth

How Wet Scrum Works!

Closing note

KEEPING TABS - TABAR'S NEWSLETTER

It's a meetup on steroids

Who comes?

18 September 2015

Headline sponsors - elabor8

Keeping Tabs - Tabar's Newsletter

Why LeSS?

LeSS Principles and Themes

So, why are companies moving to Agile?

Let's recap the Agile Manifesto to answer this question: