Craig Brown
Based in Melbourne. Works across SE Asia.
Evaluator- Better Projects Blog
- @Brown_Note
- Presentation decks
- Events - Melbourne Scrum User Group
- Events - Agile Business Analysts, Melbourne
- LinkedIn
- Contact
-
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.Even though I am based in Melbourne we can help you anywhere in the world.
-
Posts
- Jul 24, 14
What do people think about Product Backlogs? What are the opportunities here to do better?
Last night we ran a workshop at a meetup group and as I was cleaning up this morning I decided to grab some of the notes people left and capture some of the ideas in a post here.
We used the lens of the Six Thinking Hats to guide and analysis and discussion of various aspects of scrum. Here I am going to capture each of the thinking lenses and the notes made by the team who played the activity. I am interested in your thoughts as well. Please let me know what you think about Backlogs in the comments below.
Blue Hat
What is the thing we want to investigate and how do we want to work together?- Items in the backlog are interdependent
- It is hard to break down stories into smaller ones - it is unrealistic
- How big is the backlog?
- Not verified or checked
- Less Time
- Not enough info on backlog cards
- Not in priority order
- Stories get older or out of scope with time
- Often pile up endlessly
What are the facts? What do we know and not know? What do we need to get more information?- New stories are added to backlogs
- Sprint Backlog comes from the Product Backlog
- Devs pick stories from the Backlog
- PO Maps story from Backlog to Devs
- PO adds story to the backlog
- Backlog contains Epics and Stories
Black HatUh oh. What could go wrong. Where is the danger here?- The backlog is just HUUUUUUGE
- Backlog grows with time
- Priority changes
- Ongoing new triage issues coming up
- Grooming often missed
- Showstopper or production bugs
- All backlog items not getting discusses in one meeting
- Someone quits in a team
- Backlog is not consolidated at one place
- Duplication of issues
- Difficult to prioritise huge backlog within time
- Backlog tool is slow
Green HatChallenging and provoking the status quo- Review backlogs after every sprint
- Pick fixed number of stories every sprint
- Group items in the backlog
- Visualize the backlog- burndown chart
- Groom the backlog
- More discussion on priority/prioritization
Yellow HatLet's be optimistic- Everyone agrees to use same tool to consolidate
- Motivation is high
- No timezone/geographic differences
- Awesome PO and engaged team
- Grooming sessions done regularly
- Requirements are freezed (sic)
- No bugs in new development
Red HatHow do I feel? Aka emotional response- Epic stories need lots of time to complete
- Many stories can't be completed in time
- All stories are epics
- PO will just keep adding stories
- Let's do it
- Jul 09, 14
Edward de Bono came up with the idea of "Thinking Hats" as a metaphor for different ways of thinking in the mid 1980's.
What can thinking differently do to your understanding of Scrum and the way you work?
I have run this workshop activity several times with Scrum teams and Agile Meetup Groups and people always find new ideas and get new energy for improving the way their team works.
This session is designed to give you two outcomes;- A tool to take back and run with your team that will generate new energy and enthusiasm for improving the way you work
- Through participating in the workshop you will personally gain new insights and ideas about what you can do to help your team improve.
If you are interested in this activity and in Bangalore on 23 July you are welcome to join us.
Sign up via Meetup.com here. - Jul 07, 14
Consider how you act when your wallet is full versus when it is empty. When you are employed versus when you are not.
What does this mindset do to change management initiatives? How does it affect the way you run projects? What are you doing to address the issues you see in front of you?
Little things matter when you don't have money. Costs matter. You pay attention to risk. You worry about threats. You are thinking about the future.
When you are flush with cash you are thinking about how good things are. Risk identification seems like hard work. You spend money on $4.00 coffee and $20 lunches.
Consider this in the larger scale. You are in a company with declining revenues, or spiraling costs. What is the mindset in the company? What is driving decision making? - Jul 03, 14
Sometimes you'll find yourself in a situation where fortnightly retrospectives are feeling like a waste of time; the same topics are covered, no significant changes are happening to the environment, and there is a sense that the time could be better spent on other things.
Maybe you just need to stick it out and work through the barriers. Sometimes you need to bring in some innovative or fresh approaches to running retrospectives. Sometimes though, it's time to move on to something else.
Reflective learning is great, but it doesn't come in one shape only.
Before there were retrospectives there were Post Project Reviews, and before that there were After Action Reviews.
After action reviews are held after a mission is completed. If you are running three year projects you probably need to look back over the three years and learn from them, but waiting three years is a long time to go between lessons.
These days we usually work in smaller time-frames; weeks, months and quarters. At the end of each mission we have an opportunity to look back at it holistically (rather than just an abstract period of time) and reflect on how we went in the context of the business or customer goal. - Jul 03, 14
- Jun 30, 14The Schneider Culture model is popular in agile circles these days to talk about why certain agile approaches and methods work better than others in different organisational contexts.
To understand the model it is worth taking the time to go beyond Wikipedia and go read Bill's writings directly. One useful article is core to this discussion;
Why Good Management Ideas Fail - Understanding Your Corporate Culture
A diagram that I found particularly interesting in this article talks to what practices play to the strengths of what cultural styles. I present it here for your observation.
Perhaps you'd like to look at it and reflect on what agile methods and practices live in which quadrant, and whether in fact these methods easily slide into one domain or live in different domains.
I have used this in some team building and training workshops and come at this from the perspective that people's own world view will colour their answers as much as any facts about tools and techniques.
For example, where does visualizing work live? Is it about getting control, collaborating, or mastery? I suspect the answer is not embedded in visualizing, but in what problem or opportunity you are addressing.
Anyway, I'd love to hear your ideas on this model; where do you live personally in this matrix, is it the same place as your team? What about the broader organization? And given that, where do your agile methods live? - Apr 26, 14
"You can't have project management and be agile," shout the hordes of emancipated software developers.
"Agility requires freedom from command and control" proclaim the coaches.
"There is no role called 'project manager' on an agile team" advise the consultants.
Except, Agility is an adjective, not a noun.
You may have come across a movement in the online Agile chatterati that challenge the notion of 'doing Agile' in favour of 'being Agile.' It's often the same people championing this idea, as the ones that cry out the top three declarations.
Does being agile simply mean applying the principles? Is this a guaranteed improvement over other things?
There are plenty of exceptions to the rule to make agility a universal solution, but as a set of ideas and principles to explore, it has a lot of potential in a lot of places right now.
Given this call to ideas and principles, why can't you be an agile project manager?
I'd argue that there is an opportunity to expand the agile toolkit with a range of good collaborative and transparent practices out of the project management body of knowledge (not the PMI manual, but the wider knowledge set.) What is to be gained by ignoring what has already been learned before? - Apr 16, 14
A good test of whether you do know your theory is if you can explain it using multiple reference lenses.
So for example, why does time boxing seem to work?- Is there a social reason?
- Is there a neurological explanation?
- Is there a behavioural reason?
If you can pull off two answers to these questions, great job.The next question to challenge yourself is where are the limits?- In what circumstances will this theory or practice fail to deliver?
- Why is that? What are the implications to the theory?
For a nice roundout, go and try it out in a domain where it is not usually applied (eg cooking for a dinner party in time boxes) and see what happens to the theory under pressure.Good luck - Apr 16, 14
Once upon a time Project Managers were known to manage teams and resources to make stuff that is a Big Deal. It was almost like being a Project Manager was a destination. These days it seems like job title inflation has pretty much made project manager the job description you give to anyone who is supposed to chase stuff up and get stuff done.
- Apr 11, 14Justin wants his team to be successful. He wants them to create a great software product and so he does more than goes out and listens to customers, more than sharing insights with the team, more than balancing competing agendas from things like UX, engineering, sales and others.He also does things that encourage a spirit of comradeship, like getting up early, shopping and cooking the team breakfast on the day a team member is moving away.Good on you Justin. And thanks for the bacon and egg sandwich you cooked me.)
- Mar 15, 14The work of Dr. Alistair Cockburn has informed and influenced my practice both as a software developer and as a business analyst over many years. More recently I have had cause to engage more deeply with his work (amongst that of many others), as a result of my (ongoing) attempt to write a PhD. Through sheer good luck, I had my first opportunity to hear Dr Cockburn speak about 12 months ago, the context was rather weird: this was at a local meet-up group which took place in a very odd venue (as they often do). The session was supposed to be a presentation on some aspect of Agile business analysis; however, the venue, which was a bar, did not offer a single large space, but rather lots of smaller irregular spaces and had nowhere from which a presentation could be delivered. So, we got a demonstration of how a master speaker and presenter is able to adapt both content and delivery on-the-fly.Earlier this year, I came to hear that Dr. Cockburn going to be in Melbourne again – speaking at various venues and events – and would be delivering his Advanced Agile training course during March. I got very excited about this, although having neither the time nor the money to attend presented a minor problem. I was fairly sure it would have to go back on my bucket list but luckily a bit of fancy footwork combined with some weekend assignment marking presented an opportunity; so I grabbed it and signed up.My lifetime preoccupation with collecting post-nominals has meant that I have attended a silly number of classes, training courses, workshops and other such events; most of which promise to emit a better, faster and more remunerable version of the participants. This one makes no such promise: reading the synopsis made me wonder whether I had accidentally signed up for fire-walking, or BASE-jumping as a path to self-knowledge. Two days out, I was getting a little nervous.
Ah Ha Gelato I wanted to be challenged – and I was not disappointed – participants got kicked out of their comfort zone before morning tea on day one, by lunchtime you knew there is no going back. This is absolutely not talk and chalk; it is a hard mental and emotional workout and depending on the venue - which may require you to do a lot of running up and down stairs - a free physical workout as a bonus. The concepts and ideas that made up the syllabus were things I thought I knew and understood, but now I was being asked to unpack and reconstruct understanding and validate my assumptions. Hearing what was actually behind an idea, how it came to be and what its real intention was caused me to rethink and reframe. Each idea was offered up for discussion and then demonstrated through activities and exercises – some of which were surprisingly hard – all of which were illuminating in surprising ways. I don’t think I was alone in this view; I am guessing this because we were asked, to write “ah-ha’s” on stickies as they occurred throughout the course and stick them on the wall. By the last day of the course the room looked like a rainbow gelato.The key take-away for me was a much deeper understanding of why and how the behaviours and beliefs about Agility that we see every day occur; particularly why and how these beliefs trap people in less than optimal situations and more importantly why it was never intended to be that way. I have some new tools in my tool kit and some existing tools have been revised and are now ready to be reused, but not in the way I have used them before.Dr. Cockburn is an excellent teacher – as you would expect – as well as being highly entertaining and extremely cranky if you don’t follow instructions (we were warned about this on day 1). This is a course you could do more than once, getting more or different things out of it each time.My summary, if you can- you should do this[1].[1]I was not asked to write this review and have no affiliation, commercial or otherwise with anyone or any organisation related to the delivery of this course. I paid my own course fee and was on leave from employment at the time. - Mar 08, 14That’s not real Agile!I have heard and read this a few times recently in various contexts, including that of my own day-to-day work and it bothers me. It’s usually been in the context of some transgression of the rules of some methodology or another. An example that comes to mind is choosing to delay the start of a sprint for a day in order to deliver an item that didn’t make it all the way to “done” within its sprint. The team took the decision, in the interest of meeting a specific business need. There are lots of other small examples, many of which are responses to various “real life” business scenarios. We accommodate the various levels of maturity, (in terms of Agility) across our organisation, because, hey, for now, that’s just how it needs to be.Does this make us not Agile? We use the scrum guide as a framework for the way we work, but we don’t do everything exactly as it describes. Does this make us not a scrum team?If you’ll bear with me, I’d like to try to unpack my thinking about this a little.The first thing that comes to mind is that this is a symptom of our immaturity as an Agile organisation. Yes, we (the dev team) have sprinted together 23 times; yes, we have learned, we have inspected and adapted and we continue to do so. But it’s slow; the changes are fundamental and have impacted every aspect of how we do our jobs – we are still trying to find our sweet spot. Over time the changes to the development process have percolated through the organisation and are forcing change in other areas. This has been very much the case recently, as we move into a trying to cater for a dev-ops scenario. I suspect that the extent to which changes to the development process have impacted the wider company are a bit of a surprise to many, and it’s not necessarily a welcomed one.From that perspective I would argue that it doesn’t matter, we will get there. This assumes that “there” is some place where we follow a set of rules perfectly and that this is a desirable end point. However I’m not really sure that this “means-to-ends” thinking is actually what it’s all about and I can’t help but wonder whether striving for adherence to the rules is a bit of a red herring.When I look at what we do from the perspective of the values described by the Agile manifesto I’m not so worried…Planning to accommodate the needs of an operations team – who definitely have not made a conscious choice to change their approach to an Agile one – seems to align quite nicely with the value of individuals and interactions over processes and tools, as does working with marketing and PR in the same way. Each time we do this, we get a little closer to aligning our perspectives. Isn’t this what iteration is really all about? Working together with the business is not just about collaborating on the direction of our product, but is just as much about understanding that being totally transparent about our progress – the bad as well as the good – can be really quite scary for a management team. Especially when in the past they were never really exposed to the messy reality of the software development except when it was too late and had already gone horribly wrong.Being willing to adjust, accommodate, listen and respond in a way that the rest of business can deal with is very much about responding to change. Forcing the change in order to follow our plan to become agile doesn’t sit so well. The same applies to seeing the business as our customer – being willing to collaborate rather than trying force a negotiation on our terms.Agile is a philosophy based on values, not a methodology based on rules. So, if everything you do is underpinned by Agile values, that makes you Agile, the rules don’t matter all that much.
- Mar 18, 14
No wonder our perception of project work is distorted.
#PMFlashBlog – Project Management Around the World – Brisbane, AustraliaBy Jon WhittyMy conversations with project managers about project management began in Brisbane a number of years ago. I started a small study (which I published as: Project management artefacts and the affective emotions they evoke) where I asked project managers a simple question to which they had to pencil sketch the answer. No words were allowed. I would ask the project managers to close their eyes and remember a time they were managing a project. I then say, “Now answer this question by drawing the answer”. The question is “managing that project was like {draw}” And what they draw is most revealing. They certainly don’t draw a Gantt chart!What I discovered from this simple experiment is that our perceptions of project work is massively distorted by the various common artefacts (billboards if you like) of the project management community. The Gantt chart is a prime example. It reflects very little of the project experience ahead. An itemised to-do-list would do a better job. And in many cases I’ve found this is actually what is used.To explore this further consider how pictures are manipulated every day. And these images can have an enormous distorting influence on our view of the world and of ourselves.I’d like you to watch this ‘Dove Campaign’ video from start to finish. And as you watch it consider carefully the impact the final image has on both the model and you and I who encounter his picture at the bus stop.No wonder we have negative images of our own working practices.
In a previous version of this post I said “I’d love to be able to create a video someday to show the creation of the Gantt chart in a similar way." And here one is!On the left is how project managers really experience a project. And on the right is a manipulated and distorted version of events.This is tinkering with reality in so many ways. The Gantt chart smooths out the turbulent, emotional, punctuated, messy, and unforgiving real world into smooth, modernist, calming and confident lines. The real pictures are packed with emotion, jaggedness, and non-linear relationships. None of them are even the same! If a project is anything, it’s personal and experienced personally. Yet somehow we have been duped into believing that all projects can be represented by a Gantt chart.And anyway the Gantt chart is altogether the wrong piece of art work to represent the work of a project. What it does represent it an operational production environment. If you want to know more about this then take a look at the writings of PatrickWeaver and TerryMcKenna.I think the project management practitioner community should take a long hard look at their use of Gantt charts. Don’t wait for the project management professional bodies to do it because the Gantt chart reinforces all of the ideals these bodies base their certification on.From my many conversations with practising project managers I would say that the Gantt chart lowers their self-esteem about their work practices. And furthermore it raises the expectations of senior management to unrealistic heights.If you can’t achieve what’s on your Gantt chart, don’t you feel out of control?Perhaps we should put warnings on Gantt charts saying that the real world has been manipulated to look harmonious, ordered, and in control. - Feb 12, 14
Hey Readers, I have some Agile Goodliness for project and product managers and people who lead agile teams.
I'll be pairing up with Alistair Cockburn to deliver a 2 day course on Agile Project Management on 24-25th February. Share this link around and encourage people you think will be interested to sign up.
Alistair will also be leading a three day Advanced Agile Masterclass course from Tuesday 11th to march 13th as well. This is an opportunity to have your assumptions and habits challenged and for you discover new ideas and better ways of working.
Both sessions are guaranteed to challenge assumptions and open new perspectives.I'd really appreciate it if you could share this across your networks so that we can get as many people across this as possible. - Jan 25, 14A Conference Call in Real Life
"Have you been here the whole time?"
This, is my life. - Jan 18, 14
I recently found myself in a Melbourne bar, chatting with a group of Agile folks. I had just met someone for the first time and as we were both business analysts as well as keen Agilists, we found plenty to chat about. At some point during the evening, we discovered we were both Trekkies and tossed around the idea that both Spock and Data must have been business analysts. We agreed to co-author a blog post on the topic, that I would still like to do, so this post is not it, but it is the result of subsequent mind wanderings on my part.
The scrum guide defines the characteristics of the scrum master as someone who gives service to the product owner, the development team and the organisation: they are a servant leader who's prime directive is to serve the organisation by selflessly facilitating the success of others. The product owner's key characteristics are accountability and transparency, the product owner's prime directive is to ensure that the needs of the business are reflected in the product backlog and that the development team has all the information they need to meet those needs. This is also servant leadership, with their success being dependent on facilitating the success of others and being accountable for the decisions they make.Facilitating the retrospective... Jean Luc, has characteristics of both of these roles, yet my first thought was that he was definitely a product owner, responsible for carrying out the work of the business (Starfleet); accepting responsibility for not only completing the mission, but also for keeping the ship and the crew alive and well. Thinking about it a bit more, specifically how Picard goes about his duties and his demeanor, I decided that he was in fact the scrum master. Picard did not choose his missions, the product owner (perhaps Starfleet) did that, Jean Luc then set about the process of facilitating his team - the senior crew - to carry them out. Jean Luc was a leader, teacher and protector of his team; and much like many scrum masters, perfectly willing and able to roll up his sleeves and cut code if required.Peer-reviewed by Tavis Ashton-Bell (muso, composer, academic and critical thinker; the root cause of the Chess Blog series) (suss him out) - Jan 07, 14You've decided on a career change. Formerly you all were BAs, PMs, Architects or whatever, but now you've all decided to become jockeys (you know, the guys who ride horses). Your first race will be on a horse named for the thing you did the most in your old job. What is the horse's name?
Mine is PowerPoint.
Go.
(Yes, this is absurd. Sometimes, you just need something to make the day go a little bit better and the absurd is it.) - Jan 05, 14In a previous life, I used to teach an object oriented programming unit to university students. I would have been quite happy to continue doing that for the rest of my life, but for various reasons, I had to go and get a “real” job. These days I do a little part time teaching and I’m a student again myself; consequently, I still hang around university teachers quite a bit. Recently, an ex colleague from my teaching days asked me, “How would you teach it now?” His question was from the perspective of my professional and academic interest in Agile and my response was, “Well, I would teach Agile approaches from day one of first year and by third year I would run the unit as an Agile project, of course”. He questioned me a bit further and reminded me about some of the challenges this kind of teaching holds. This got me thinking about how I would teach it now and how I would respond to some of those challenges. A quick literature search reveals that there has been some research on the topic by the CS education community but not as much as I would have expected. So what follows is a combination of some of what I learned as a teacher and some of what I have learned as an IT professional.First year fundamentals;One of the key challenges for teachers of first year programming students is managing the range of existing skills amongst the cohort; some students have never written a line of code, whilst some may have already made money by developing and selling Apps. This means you have to be able to hold the interest of the latter, and ignite a spark of interest in the former. You know you will get a high drop-out rate, since previous programming knowledge is not required, some people will quickly find that they would rather drink bleach than learn programming and disappear. For these and other reasons, it’s really hard to do group work at this level, and most introductory courses avoid it; As a result, it’s also hard to develop an approach to lab and assignment work that results in something more than an individual portfolio of unrelated code snippets.These things matter, even in first year, because the ability to not only work in a team, but to work in a cross skilled, self-organising team, is as fundamental as being able to code for a software engineer and each should receive equal attention as an educational outcome. Graduates who cannot (or do not want to) work as a member of a team are, at best, significantly less employable than those who can, and at worst, a liability to their eventual colleagues and employers. (Moreno, Sanchez-Segura, Medina-Dominguez, & Carvajal, 2012) (Vivian, Falkner, & Falkner, 2013). This means that the task at hand is to find a way to give students an opportunity to develop their practical skills and to experience the synergy that results from great teamwork. Happily, since both object oriented programming (OOP) and Agile are principle driven, there is a ready-made framework which can be put to use.Borrowing from a very successful approach to teaching OOP principles using tools like BlueJand detailed in a 2004 evaluation; I would choose to introduce Agile principles by example. I would build on each principle week by week, introducing concepts as needed. At first year level I wouldn’t try to teach a particular methodology or approach such as scrum, but would introduce ideas where they were most appropriate. For example; introducing the idea of Personal Kanban provides a nice introduction to lean principlesand is of real practical value for students struggling to manage an undergraduate workload. Since most early programming tasks are by necessity, discreet examples of a given construct such as iteration, techniques such as user story writing could help students understand what is required of them as well as providing a very natural way in which to break down assigned programming tasks into objects and methods.Addressing the teamwork issue from the get-goIn my imaginary unit, I would use the concept of pair programming to introduce students to the idea that software development is a team based activity from class one. Given the expected range of skills and experience among the cohort, the first one hour tutorial class presents as an opportunity to gather some experiential data from the students. Using this data, the teaching team would be able pair students for first lab class each pair would comprise one experienced student and one with less experience. At this level, the skills being taught are basic software development concepts, such as the use of variables, selection and iteration, depending on the tool being used, you may also have teach students how to work with an integrated development environment (IDE). Working as a pair, the students should help each other with the weaker student at the keyboard and the stronger student guiding the process. Subsequent theory sessions would then take the form of a mini retrospective on the previous week’s lab class, as well as a joint planning session for the next lab class. The pairs could be switched around so that each student had an opportunity to work with each of their colleagues over the semester. This reflects the practical workplace reality that you don’t get to choose who you work with.AssessmentAssessment is another tricky area for the educator; and is usually a key item of interest from the student perspective. At first year level, students are typically assessed against each other in terms of their skill development (or other assessable criteria); consequently they have no reason to be particularly interested in helping others, or contributing to a team effort. This is where educational design meets academic administration, quality frameworks and the need for nice bell curves. Unfortunately, this puts students at odds with Agile values, where it is the competency of the team which is assessed. So whilst it makes sense to try to align the assessment approach with Agile values, this is likely to be a challenge.One way this can be approached is to ensure that the tutorial work described above forms a hurdle aspect of the overall assessment; the basis of the assessment should be the student’s participation in the process rather than completion of specific exercises. Marks for each tutorial component should be awarded equally to the pair and the overall marks awarded should be a worthwhile amount. The idea that pairs should change each class would go some way towards managing pairs where one student does all the work,Assignment workA common pattern for assignment work is for students to be asked to submit two or three individual programming assignments in the form of working tested software. Each assignment should build on the previous one eventually delivering a simple, but complete and working application. Generally, a student who has completed all the activities from the tutorial sessions should have had an opportunity to work with all the concepts required to complete the assignment work. Each delivery component would be marked individually, and be demonstrated to the tutorial group, allowing the practical introduction of the concepts of the sprint and iteration review, which would have been introduced as part of the lecture material.Tests and ExamsAnother common pattern is to require students to sit a mid-semester test and a final exam. Both the final exam and the mid semester test could be run as a coding dojo. Students could receive a brief prior and would be expected to arrive having designed a solution which they then implement within a time-box. Assessment could take the form of a review of work conducted with the tutor in order to assess student understanding, code output could be assessed via a range of automated tools including test harnesses. This approach to assessing first year programming students is not new and has been shown to work well see this paper for more information.ConclusionThis essay is by no means a fully fleshed out unit design, but proposes an approach to introducing Agile concepts to beginning programming students as an integral part of how software development works. This approach could be used to build towards a third year elective in Agile software development using scrum, where tutorial groups form self organising teams and where tutors act as scrum masters with requirements of the unit representing the product owner.ReferencesMoreno, A. M., Sanchez-Segura, M.-I., Medina-Dominguez, F., & Carvajal, L. (2012). Balancing software engineering education and industrial needs. Journal of Systems and Software, 85(7), 1607-1620. doi: http://dx.doi.org/10.1016/j.jss.2012.01.060
- Dec 21, 13Provided in two handy posts by Intuit's Fast Pace blog.Entertaining and bookmarked here for posterity.
- Dec 16, 13
I present to you a list of links to agile frameworks that address scale, multiple teams and complex environments.
After reading these I realise I have my own model I can add into the mix. Unfortunately for the world I don't have much free time to write it down. Let's see of Christmas holidays give me an opportunity...
Please take the time to read these frameworks which all purport to be tested successful frameworks for managing multiple teams in an agile way.- Agility Path by the crew at Scrum.org and Ken Schwaber
- Disciplined Agile Delivery by Scott Ambler
- LeSS (Large Scale Scrum) by Larman and Vodde
- SAFe (Scaled Agile Framework) by
Before adopting any one consider how change works and reflect on whether you want to go whole hog, and have an organisational revolution, or whether you want to take smaller steps and adapt change in an incremental and focused way. For that you could consider David Anderson's Kanban Method, or Martin Kearns and Andrea Tomasini's Agile Transitions booklet.
Thanks to John Ogden for pointing me to Peter Stevens blog which has a good post on the topic. - Dec 05, 13
I ran an open space conversation a while back asking people what it feels, looks and sounds like when you are in that special, all too infrequent place you could call "magic."
This is what they came up with.
Rather than take this checklist and apply it to your team it might be more useful to have a similar conversation with them. Perhaps a retrospective could be dedicated to what great teams are like to work in, and through that you could generate your own markers of good.Right click the image to open full size. - Nov 22, 13Tear It Down – Rands in Repose
Go read this. Now. I don't really have commentary because I just don't know what else I could ever add that would make it better.
-
Tweets
- Tonight @rooosterboy and I are running a meetup - Six Thinking Hats and Scrum. Always generates new insights :)
- RT @mlevison: Op-Ed: Microsoft layoff e-mail typifies inhuman corporate insensitivity | Ars Technica http://t.co/M7HGZ3wA63
- Am on some weird sleepless 24 Odessey from Melbourne to Bangalore... Am using beer to keep going,but am feeling my stamina slipping
- @delmo_1 it's a nice gimmick when you are standing in front of a crowd
- The things astronauts have to deal with... http://t.co/XYNMCChcoF
- Tony Abbott:"If you want to put a price on carbon…: http://t.co/vFvJcOBNNV
- @adrianwmasters I quit msm a while back but it still slips into my life via Twitter and Facebook
- The tablets v computer story... Has this factored in windows 8?
- RT @Daxton6: check out the link below and let us know on you-tube your thoughts. cheers The sweetlips - Nemesis: http://t.co/s18XGo5apG via…
- @senatormilne @MelAnalyst cheapest got you can buy
- @resi_analyst @sanderwagner can you point me at a blog post that explains that chart?
- Continuos delivery via @devopsreactions http://t.co/Mql4MTxoJb
- RT @alaindebotton: Theodor Adorno would have hated Twitter - for very good reasons: http://t.co/GNc2GkUYXt
- RT @Happy_Melly: Do you want to know how @Wikispeed builds safe, low-cost, ultra-efficient, road-legal vehicles? http://t.co/4bJXKOFbnf
- RT @flowchainsensei: “Fearful zombie companies quail in fear at the thought of an employee having an independent thought.” http://t.co/IW0L…
- Fuuuuuuuuuck #auspol
- @peterstev do you have a window for some scrum training when you are in Bangalore later in the year/
- RT @pmforpm: Touched on this @LASTconf “What Are You Doing to Feel Uncomfortable?” http://t.co/SKExLX89Yj #lastconf http://t.co/Rsdr1cbY05
- If you liked #LASTConf please check out Ed's newest venture - Dare! http://t.co/E6nqT7UFVl
-
Posts
- 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. - Sep 26, 12
Presentation by John Giles to Melbourne Scrum User group. From 26 Sept 2012 - Apr 05, 12
What should you consider when starting a project? What models and aprpaoches can help get you off to a good start? - 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! - Jun 02, 11
This is a short introduction presentation for the PMOZ conference in Sydney later this year. - 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. - 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. - 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 - Aug 05, 10
Where are we 18 months after the teams adopted scrum. Where do we want to go? - Sep 23, 09
a presentation on how a business analyst can fit themselves into an agile/scrum project. Comments very welcome. - 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. - 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. - Feb 12, 09
A guide on how to review and give feedback to business requirements documents for software projects. - Jan 16, 09
A summary of the more popular software develpment processes and methods. - Oct 07, 08
Wrapping up the intor to project management series with a skim across some conemparary issues. - Oct 04, 08
Some thoughts on the challenges of goal alignment between consultants and clients
-
Posts
- Jul 24, 14
Melbourne Agile and Scrum User Group
A reflection session. What inspired you recently and what have you done about it? A series of small conversations or short talks.
Can be inspired by stuff from LAST conference or other places.
Melbourne - AustraliaWednesday, July 30 at 6:00 PM
Attending: 60
Details: http://www.meetup.com/scrum-12/events/148222312/
- Jun 24, 14
Melbourne Agile and Scrum User Group
The "Meet the tools vendors" event has proved quite popular and so we will run it again this year. If you are involved in the promotion of a particular toolkit we welcome your participation.
This year it will be on August 27th.
To help us get organised could you let us know which tool, and who to contact as we get closer to the event.
Send us your details on the registration form here.
Thanks to Rally Software who are sponsoring beverages for this Meetup.
Melbourne - AustraliaWednesday, August 27 at 6:00 PM
Attending: 98
Details: http://www.meetup.com/scrum-12/events/159559552/
- Jul 16, 14
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - AustraliaWednesday, September 24 at 6:00 PM
Attending: 21
Details: http://www.meetup.com/scrum-12/events/166390872/
- Jul 16, 14
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - AustraliaWednesday, October 29 at 6:00 PM
Attending: 11
Details: http://www.meetup.com/scrum-12/events/181142562/
- Feb 19, 13
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - AustraliaWednesday, November 26 at 6:00 PM
Attending: 4
Details: http://www.meetup.com/scrum-12/events/181142602/
- Feb 19, 13
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - AustraliaWednesday, December 31 at 6:00 PM
Attending: 3
Details: http://www.meetup.com/scrum-12/events/181142642/
- Feb 19, 13
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - AustraliaWednesday, January 28 at 6:00 PM
Attending: 2
Details: http://www.meetup.com/scrum-12/events/192520122/
-
Posts
- Jan 07, 14
Agile Product Owners and Business Analysts, Melbourne
Tonight you'll be continuing the design of a framework for personal development.
The focus will be on Discovery techniques and practices. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
We will be breaking into groups of 4-5 and working through the following sub-topics.
• Understanding Stakeholders
• Think like a customer
• User needs and habits
• Bridge understanding gaps
We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
We will collect your content and over the year publish a shared framework for a personal development plan or training course.
Hosted by Shadi Zandi and Craig Brown
ICAgile reference
Melbourne - AustraliaTuesday, August 12 at 6:00 PM
Attending: 50
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159139792/
- Jan 07, 14
Agile Product Owners and Business Analysts, Melbourne
Tonight you'll be continuing the design of a framework for personal development.
The focus will be on Discovery techniques and practices. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
We will be breaking into groups of 4-5 and working through the following sub-topics.
• Amount of context needed
• Type of context needed
• Seeing the whole
• Maintain value at all levels
• Know the contraints
• Determine risk
We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
We will collect your content and over the year publish a shared framework for a personal development plan or training course.
Hosted by Shadi Zandi and Craig Brown
ICAgile reference
Melbourne - AustraliaTuesday, September 9 at 6:00 PM
Attending: 44
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159139862/
- Jan 07, 14
Agile Product Owners and Business Analysts, Melbourne
Tonight you'll be continuing the design of a framework for personal development.
The focus will be on Attributes of the role. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
We will be breaking into groups of 4-5 and working through the following sub-topics.
1. Feedback
• Receiving feedback
• Communicate with examples
2. Managing Artifacts
• Defining done
• Progressive elaboration
• Understanding what is do-able
• Avoiding waste
• Assess and validate delivered value
• Prioritize for value
• Slicing and chopping
We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
We will collect your content and over the year publish a shared framework for a personal development plan or training course.
Hosted by Shadi Zandi and Craig Brown
ICAgile reference
Melbourne - AustraliaTuesday, October 14 at 6:00 PM
Attending: 31
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159140152/
- Jan 07, 14
Agile Product Owners and Business Analysts, Melbourne
Tonight you'll be continuing the design of a framework for personal development.
The focus will be on Attributes of the role. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
We will be breaking into groups of 4-5 and working through the following sub-topics.
1. What we can control
2. What is beyond our control
We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
We will collect your content and over the year publish a shared framework for a personal development plan or training course.
Hosted by Shadi Zandi and Craig Brown
ICAgile reference
Melbourne - AustraliaTuesday, November 11 at 6:00 PM
Attending: 26
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159140342/
- Jan 07, 14
Agile Product Owners and Business Analysts, Melbourne
This month we review the development plans we collectively work on during the year and map it back to the ICAgile framework.
We'll also explore how we can deploy the course to our peers and network.
Hosted by Shadi and Craig
ICAgile ref: http://icagile.com/fi...
Melbourne - AustraliaTuesday, December 9 at 6:00 PM
Attending: 13
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159140562/
- Jan 07, 14
Agile Product Owners and Business Analysts, Melbourne
Tonight you'll be continuing the design of a framework for personal development.
The focus will be on Attributes of the role. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
We will be breaking into groups of 4-5 and working through the following sub-topics.
1. Role, Scope, Diversity
• Role, not Title
• VM-BA and Other roles
• Adapting to context
2. Attributes of the role;
• Bridge, not ferry
• Keeper of responsible decicions
• Big Picture View
We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
We will collect your content and over the year publish a shared framework for a personal development plan or training course.
Hosted by Shadi Zandi and Craig Brown
ICAgile reference
Melbourne - AustraliaTuesday, January 13 at 6:00 PM
Attending: 7
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/181029992/
- Jan 07, 14
Agile Product Owners and Business Analysts, Melbourne
Tonight you'll be continuing the design of a framework for personal development.
The focus will be on Attributes of the role. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
We will be breaking into groups of 4-5 and working through the following sub-topics.
1. Role, Scope, Diversity
• Role, not Title
• VM-BA and Other roles
• Adapting to context
2. Attributes of the role;
• Bridge, not ferry
• Keeper of responsible decicions
• Big Picture View
We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
We will collect your content and over the year publish a shared framework for a personal development plan or training course.
Hosted by Shadi Zandi and Craig Brown
ICAgile reference
Melbourne - AustraliaTuesday, February 10 at 6:00 PM
Attending: 4
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/181030012/
- Jan 07, 14
Agile Product Owners and Business Analysts, Melbourne
Tonight you'll be continuing the design of a framework for personal development.
The focus will be on Attributes of the role. This is drawn from the ICAgile model for the Value-Manager-Business-Analyst.
We will be breaking into groups of 4-5 and working through the following sub-topics.
1. Role, Scope, Diversity
• Role, not Title
• VM-BA and Other roles
• Adapting to context
2. Attributes of the role;
• Bridge, not ferry
• Keeper of responsible decicions
• Big Picture View
We will look at each of these topics, consider learning objectives and activities we can create and share activities and methods for learning these ideas in and among our local communities of practice.
The format will be small groups get together, work in iterations across all topics with a group sharing section at the end of each iteration and then a debrief at the end of the night.
We will collect your content and over the year publish a shared framework for a personal development plan or training course.
Hosted by Shadi Zandi and Craig Brown
ICAgile reference
Melbourne - AustraliaTuesday, March 10 at 6:00 PM
Attending: 2
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/183866252/
- Jan 07, 14
Agile Product Owners and Business Analysts, Melbourne
Melbourne - Australia
Tuesday, May 12 at 6:00 PM
Attending: 1
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159140552/
-
Info
- Co-founder and Chaos broker at LAST ConferenceManagement Consulting | Melbourne, Australia, AUSummary
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 - PresentTeam Member / Aconex
- Jul 2013 - PresentCommunity 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 - PresentCo-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 - PresentDirector / Evaluator.com.au
Consulting business that helps you understand how to improve your project and technology performance.
- Jul 2012 - Aug 2012Program 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 2012Head 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 2012Occasional Agile Trainer @ Telstra / Accenture
Participating in the agile adoption at Australia's largest telco.
- Oct 2010 - Jun 2011Consultant / 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 2010Program 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 2010Lecturer / Melbourne Institute of Technology
Lecturer in Project Management to Masters degree students.
- Apr 2008 - May 2008Consultant / St George Bank
Project recovery and strategy work.
- Jul 2005 - Feb 2008Project 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 2007Project Consultant / ANZ
Working via OptimiseIT
- Dec 2006 - Apr 2007Project Manager / Telstra Business
Managing new products to launch for Testra's business customers.
- Sept 2003 - Feb 2007Director / 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 - 2005Various 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 - 2007RMIT UniversityMasters in Project Management
-
1990 - 1994University of NewcastleBachelor in Business
Activities: Student Union member, Editor of campus newspaper, BBQ organiser, ahh good times... -
1983 - 1988Henry Kendall High School
Additional Information-
Websites:
