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
- 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. - Nov 08, 13Around this time last year, the UKs Association for Project Management (APM) Knowledge SIG held its first Courageous Conversation event, and I was really pleased to be part of it. Here is the video of the discussion that took place. If you watch it carefully and perhaps a couple of times, you will see the conversation really challenges our perceptions of the project management body of knowledge (BOK). Personally I thought the APM were courageous in supporting this event. The sound kicks in after 40sec.
On the 3rd December this year the APM Knowledge SIG are hosting another Courageous Conversation event, and I’m sure it will be as disclosing as the previous one. It will be in Oxford this time.
The topic this time is set to challenge our preconceptions about project management knowledge management, and it begins by proposing the following provoking question:
Why is knowledge management (KM) in project environments 20 years behind KM in the rest of the world?
I thought that in the spirit of the courageous conversation I would add my comments here, and perhaps it would help fan the flames a little.
On this matter I believe that the project management (PM) professional bodies are massively to blame. But it’s not their fault! They don’t do it intentionally. It’s just a consequence of how they operate and how they see themselves operating. Knowledge management in project environments is 20 years behind knowledge management in the rest of the world, partly because of the antiquated business model of the professional bodies and partly because most projects that fail don’t kill hundreds of people as a direct consequence.
Let me briefly tackle both of these points. First their business model, and second the consequences of failing projects.The Business Model of the PM Professional Bodies/Institutes: Frozen in time
The business model of the various PM professional bodies or institutes such as the APM, PMI, AIPM etc. is stuck somewhere in the 1980s. Let’s not forget that each of these entities has full-time staff and premises. Their business model needs to at least support their commitment to these by generating revenue streams. The money comes in mainly through membership fees and the registration/licensing fees they charge training providers to register with them. To make the financial model work, they create levels of certification around a particular artefact in the form of their own book or project management body of knowledge or ‘BOK’.
A quick response to the courageous conversation question is that the business model (centred on creating BOK artefacts that underpin revenue streams such as certification, membership, and training provider agreements) is stuck somewhere in the 1980s. Consequentially this impacts on the PM community and creates a 1980s view of KM in the project environment. This seems to be the same sort of behaviour Alan Clark generated in the late 80s/90s in the UK when he crafted the national vocational qualification framework (NVQ).
Alan Clark was the Minister for employment, trade, and defence in Margaret Thatcher’s government. He fine-tuned this model and his diaries spell out the business model very well. Basically, the NVQ (national vocational qualification) was born in response to political promises to increase the qualification level in the UK workforce. The idea was to give people qualifications for the things they can already do! So let’s say you work on a production line soldering components into a printed circuit board. Realistically there are no qualifications required for doing this job, only a few hours training. But an NVQ can be created for this, and a whole workforce can be newly measured and qualified. But why would an individual want this NVQ? And why would an employer demand that their production line employees have this NVQ? Furthermore, why would anybody possibly want a qualification for a job that they can already do? These are all probably logical questions to ask. But logic goes out the window when political promises have to be kept.
So Clark (or more likely his team) put together a business model to increase the number of people in the workforce with a NVQ. The business model was pretty simple. Firstly, you created some sort of badge that everybody had to have before they could apply for tenders for subcontract work from any government authority. In this particular case the badge was the ‘Investors In People’ (IIP) badge. The marketplace was given say 3 to 5 years, and within that time you had to have an IIP badge. It was a rather nice wall plaque to hang in the reception area, and a logo for your letterhead. Secondly, you defined the criteria for being awarded this badge (or levels of it) in terms of the number of employees on your staff that held a NVQ. Thirdly, you licence training organisations with the ability to award NVQs. And off the business train goes!
Organisations at the top of the food chain began to appoint full-time staff to the role of managing their IIP status. NVQ performance criteria or competency standards were created by various bodies, and training organisations marched out into a NVQ hungry marketplace. The market was hungry for NVQs - If they didn’t have NVQ’d people in their workforce, they weren't able to contract with government agencies. An interesting by-product of this behaviour is that when an employee is measured against a set of competency standards (remember this is for a job they are already doing and have been doing for many years), they are found to be ‘non competent’ or ‘not yet competent’ in some areas. Of course the training organisation conducting this competency measurement inevitably has a training program that the organisation can tap into that will increase the competency level of their workforce. Training organisations have their NVQ assessors, and these assessors need to be trained and assessed. So there is a niche market for a trainer of trainers and assessor of assessors. Yes you can get an NVQ for that too!
This industry (and it is an industry) is founded on the creation of an idea that there is a real need for NVQs. What if there is no real need? Does this business model sound familiar? Just replace the ‘Investors In People’ framework with any Project Management Maturity Program you wish, say P3M3 or OPM3. Then set the criteria for moving up the levels in these programs in terms of how many PRINCE2, PMP, RegPM, APMP, or IPMA Level D certified people there are in the organisation’s workforce. Finally, licence training organisations to award these certifications and deliver the necessary training, and you’ve successfully created an industry pretty much for the sake of the industry.
But a significant problem with this business model is that it is anchored in the past by a physical document -the so-called body of knowledge (BOK) that has to have its contents agreed upon and sanctioned by the particular professional body. As you can imagine, the cycle for changing the contents of this BOK document is long and unwieldy. It is therefore within the interest of the project management industry not to change it. And that is how you stifle the knowledge base of the project management profession and lock it in a mode that is constantly trailing a decade or two behind where it needs to be.The unseen consequences of failing projects: they don’t fall 30,000 feet, but there are casualties
If you flew on an aeroplane a 100 years ago and something small went wrong, there was a good chance you’d crash, and a good chance you’d die. Today, the commercial aviation industry is the Gold standard for safety and accident prevention. Even medical surgery is learning from them. Aviation has achieved this fantastic transition because the consequences of its failures are self-evident. No one would step in an aeroplane unless the aviation business could demonstrate that it learnt from its failures. But that is tragically not the same for project-based organisations. When projects fail, and they do so every day, hundreds of people do not die. But there are casualties. Jobs are lost, some careers are ruined, companies slowly collapse, mortgages are unpaid and stress in the workforce rises, with consequences for health, well-being and families. There are casualties when projects fail. But because the casualties and consequences are not so publicly visible, we somehow don’t feel compelled enough to figure out why and to stop repeating the behaviour that leads them to fail and to manage the knowledge our organisations gain through project work. And so, returning to the courageous conversation question, knowledge management in project environments receives little more than a passing interest.
But we could do better than this. We could employ the concepts of aviation safety in our project based organisations. In the same way that every aeroplane that leaves the runway is an opportunity for the aviation business to learn how to fly planes better tomorrow; every project can be an opportunity for the project-based organisation to run better projects tomorrow. Here’s a video presentation on how to do this.
The model presented is simply a conceptual model to demonstrate how knowledge about doing something is distributed across various features of our organisations. It is a network approach. And if you watched the first courageous conversation video at the top of the page, you will see that this model is a practical application of the ideas presented there.
And so to some courageous concluding remarks on this matter: The business model of the project management professional bodies and institutes is not serving the project management profession well. It is simply serving itself. I have a feeling professional bodies know what to do, but somehow lack the courage, or the knowledge, or the mechanisms to do it. This morning I read on the APM Blog a posting called “listening to the profession” and there are tones of what needs to be done in there. The concept of where the BOK is needs to be challenged. The BOK is not a book, or a PDF, or an electronic web based form of a book like Wikipedia which is updated by a professional body. The body of knowledge on how to successfully and unsuccessfully deliver projects across all domains and disciplines is distributed across the community of project management practitioners in those domains and disciplines. All you need is a mechanism for asking them and tapping into that knowledge.
If you are facing a challenge in your project, would you rather refer to a book of generic principles, or would you rather ask somebody who has experience in dealing what you are struggling with. All you need as a project management practitioner is a platform for asking this community, and the platform will help you find the right person to ask. This network platform should be, in my opinion, the business of the project management professional bodies. The true project management body of knowledge is a living dynamic thing, and these professional bodies should be connecting it up and making it work. It is, in a way, already doing this via its branch and chapter meetings but these physical networking devices should be brought to the front and centre of the business model. This is the sort of major courageous change the project management professional bodies and institutes need to embark on in order to shift the profession’s practice of knowledge management into a new and higher level of thinking. - Dec 04, 13
Installing scrum - the hard way
A year ago I joined a new team, my goal was to introduce this team to Agile methods and approaches to software development. I was looking for a challenge and an opportunity to learn and I found one.- So just in case you are looking for a challenge, this is what you need if you want to install scrum and do things the hard way.
- You need a project, preferably one running at least two years late. It must be huge and complex; critical enterprise level software is good, a platform change is also good; both at once are best.
- Your project must be in an unknown state; there must not be anything that looks like a source of truth about the overall scope or the current state of the project. It's good when the business is unaware of this, because you get to tell them.
- It's particularly helpful if your project has accumulated a significant amount of technical debt, as a result of development shortcuts taken in order to meet unplanned business needs. There must not be a clear picture of the amount of TD nor must there have been any thought given to paying it off. Ideally your TD should become apparent at the least convenient moment.
- The team should not have had any training in Agile methodologies, or their associated vocabularies. Terms like “retrospective” and “backlog” should be completely foreign. The idea of a value-based approach to working should not have been broached at all.
- There should not be either budget or time for training, any training that is done must be strictly on-the-job and should not mean that the job takes any more time than the minimum required.
- There will be no visible use of story cards, burn down charts or any other form of publicly shared information radiator. These including things like the daily stand up must be kept out of sight of anyone who may find them a distraction or feels they look untidy.
- The practise of continuous integration, or the infrastructure to support it, must not be established. This means that you will need to put it in place as you go and you get to experience regular integration hell.
- Things like an established QA team or QA process and especially automated testing are a real nuisance. This deprives you of the challenge of trying to regression test an increasingly large code base by hand as well as all the fun associated with putting automation in place and ensuring your practises support it. There shouldn't be any additional budget for this either.
- It's best if your team is used to working within the confines of very clearly defined roles and are not in the habit of collaborating to decide the details of what should be built and how long it will take to build. This task should be done by someone else, it doesn't really matter who, so long as they are not a member of the development team, know very little about software development and are not distracted by things like the need to develop potentially shippable increments of the product.
- Finally, you must deliver potentially shippable increments of product, from sprint 1, whilst responding to the needs of the business by understanding their goals and challenges. You must teach the team that requirements which change as a result of these are to be welcomed as opportunities to build the right thing, meanwhile, learning the product and domain.
- We still have a large complex project, but we know exactly how much of the total scope we have built, and how much is yet to do. We have a release schedule and are totally unified in our commitment to meeting it.
- We regularly schedule activities such as re-factoring into our sprint plans, in order to manage our existing technical debt. We still accumulate new technical debt, but when we do so, it is the result of a strategic decision and we include its management and remediation in our planning.
- The team and the business have been gradually introduced to the values, philosophy, practises and rules of scrum. This has been done one tiny piece at a time, gently and quietly, leading by example coaching continuously and seizing every teachable moment possible. Gradually we have seen the language change and the framework and practises have become familiar and welcomed.
- We don't have a physical story wall, but we do have an electronic one that every member of the organisation has full access to. We have practised transparency through this tool by sharing our successes and failures openly and consistently.
- We have a shared repository of lightweight but permanent artefacts to support requirements and testing work. Because we know this product will outlive this team, we share responsibility for developing them and keeping these up to date.
- We do have continuous integration, as well as (for the first time recently) separate QA and UAT environments, although we still don't have fully automated testing. This is our next challenge, and we are very focused on developing the skills we need to introduce full automation. In the meantime, we are collectively a lean, mean testing machine
- The demarcation of individual roles and tasks is a distant memory. Everyone applies all the skills they have where they are needed, when they are needed.
- We work directly with the business to plan our releases at the theme level, our product backlog is about 90% estimated in story points and our detailed sprint planning is done by the team, in accordance with the rules of scrum. We are getting much better at estimating our work and breaking stories down into useful task lists.
- We delivered our first shippable increment in sprint 1, our first shippable release into our sandpit area for client feedback in March of this year and have continued to deliver two updated releases and increments every sprint and will shortly deliver our first release to go directly to client environments. Along the way, our product has been showcased to clients, has enabled us to compete for tenders and has attracted interest from new markets.
Perhaps most telling on a personal level, is that I stopped keeping half an eye on the job market, quite some time ago. - Nov 05, 13Look at the chalk boards, which John Wheeler used to craft on a regular basis for his physics students. What do your walls and whiteboards communicate?
- Oct 30, 13
Wondering what book to read next?
We got a bunch of smart folks from the local agile community and asked them to bring a book to a meetup and talk about it. Check out the list below for some interesting reading ideas.- Agile Estimating and Planning, Mike Cohn
- What got you here won't get you there, Marshall Goldsmith
- Black Swan, Nassim Taleb
- Directing the Agile OPrgansiation, Evan Leybourne
- Power, Jeffrey Pfeffer
- An Agile Adoption/Transforamtion guide, Michael Sahota
- Extreme Programming Installed, Jeffries, ANderson, Hendrickson
- Leading Teams; Setting the satge for great performance, Hackman
- Secrets of Consulting, Gerry Weinberg
- Quality SOftware Management, Gerry Weinberg
- Getting Real, 37 Signals
- Oct 23, 13
- Oct 16, 13
Last week I ran a user group exploring How to Prioritize User Stories. I collected 54 written down explanations of what people do, and their reflections on the practices. And I have typed them up into a shared doc for you to read and reflect on.The list doesn't provide any definitive answers, but it does show a bunch of patterns and trends in thinking, so I am sharing it here.
The workshop method is also described in the document. The summarized version is that we asked people to write on cards what they do today and then hand the card on to someone else, who will ask questions and add insights to the notes. Repeat n times to layer ideas on top of each other.
I thought it was an interesting way to share ideas. The room was vibrant with conversation and I get the impression that many people were stimulated to go change something about the way they work.
The written down notes were artifacts that recorded aspects of much richer conversations, so they don't tell the full story.
If you were at the event I'd be keen to hear your thoughts in the comments on this post.
The notes are here. - Oct 15, 13Tonight in Melbourne we ran a discussion about Agile Project Managers with a bunch of Project Managers who are experienced with agile development, and a bunch of agile development people who are interested in project management. For people who view this that were not at the event I'll describe what happened and a couple of insights I came away with.
Peter Lam, our facilitator broke us into two groups; project managers on one side of the room, everyone else on the other. I joined in the PM team for the discussion.
The next step Peter seeded in 3 parallel questions into each group which we discussed and summarised in 15 minute rounds;
1. Why is PM/Agile (depending on which group) valuable/useful?
2. What is it about Agile/PM that is threatening?
3. What do sponsors care about?
We then broke for pizza (thanks ThoughtWorks) before coming back to one large group and putting the conversations on the whiteboard and shared key points back with the other group, shared responses to criticisms, etc
Peter than facilitated a bit of synthesis to wrap us up - "So what does this all add up to?"
You can check the whiteboard notes from the conversation in the session photos here.
Some key points that resonated with me were that from both perspectives the failures, threats, pain from the other camp were all straw men, and the issues are all about fear and uncertainty... which brings us back to culture and conversations.
Thank you Peter for a great structured conversation, that despite going for 2 hours was engaging all the way through. - Oct 06, 13DeMarco’ assertion in the 1990’s (?) that a 5% return on investment suggest a project that shouldn’t be run. It simply isn’t worth the effort.This runs counter to the typical portfolio management approach of setting return targets within a weighted super-set of benefits. In this instance we aren’t just comparing 5% with huge benefits, we are comparing a number of competing initiatives, and some of them may have only slightly different prospects.In this instance where do you invest?I am yet to see a corporate environment that runs too few, or even an appropriate number of projects for their capacity. Most have too much going on at once, and as a result are churning and wasting energy where they don’t need to.Why not adopt WIP principle at the portfolio level? Get more done and occasionally pick the wrong order or priorities, but still... get more done?
- Oct 01, 13
John Bell dies in 1990 on this day. JOB was awesome because he was a challenger. Bell's theorem challenged quantum mechanics because he figured out that either things can communicate instantly across distance (ie faster than light) or they don't exist when not being observed.
I started learning about quantum mechanics in the 1990s as a non scientist curious layman. It excites me and leaves me completely confounded despite years of reading up on it. Bell was able to work out some of this confusion to call out a meta pattern. That's amazing. Plus he looks like a high school teacher.
-
Tweets
- Chocolate eggs... Now that's fucked up
- Blah blah blah #stateofagile2014
- I think the smartest people in the world are the ones that ran a google and words campaign to buy google shares
- Clearly the 1980's win everything http://t.co/KirwLBf4E3
- It's interesting working at a place where people are so super engaged. The usual moaning about typical stuff is so not an issue
- My mate is looking for Agile Mainframe stories. Can you help?
- My friend Venky is looking for Agile Mainframe stories. Do you have one you could share?
- "gave that backlog a brazillian" (trimming it from wide clumps of Post it notes to a single ordered strip)
- RT @berndschiffer: Upcoming: Scrum Coaching Retreat Thailand 4-6/12/2014 http://t.co/QnMtd0X2qY I plan to attend. Are you in?
- RT @flowchainsensei: “‘Community and citizenship’ should be among a project’s central activities and measures, at least on a par with ‘code…
- RT @letvictoriavote: Excuse me? Not a vagina in sight. This is not community. #Sausages. "@Vic_Premier & Ministers met #SpringSt http://t.c…
- RT @GreenpeaceAustP: Because you'd have to be pretty stupid to support renewable energy #australiansforcoal @Austs4Coal http://t.co/L6vWfAJ…
- @tookwancottage not too different
- Good PM's cook their teams bacon and eggs on rainy Fridays http://t.co/aFLpg86efu
- Scaling Agile workshop in Bangalore http://t.co/S9IzbHwW11
- Hey, do any of you guys work for City of Melbourne? I have a question about community events.
- RT @SiDawson: The premise of minimum wage was that a single wage earner should be able to support a family http://t.co/hhex9q1jB1
- RT @JeremyScrivens: Rather than looking at what's wrong, an #Adelaide #hospital is using #AppreciativeInquiry to identify the best of #ICU …
- @juddotcom Lol, "literally"
-
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 - 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
- Jan 09, 14
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - AustraliaWednesday, April 30 at 6:00 PM
Attending: 41
Details: http://www.meetup.com/scrum-12/events/147672012/
- Feb 24, 14
Melbourne Agile and Scrum User Group
Adapting to the team. From agile to lean to lean startup.
Hawthorn - AustraliaWednesday, May 28 at 6:00 PM
Attending: 42
Details: http://www.meetup.com/scrum-12/events/147672322/
- Feb 19, 13
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - AustraliaWednesday, June 25 at 6:00 PM
Attending: 8
Details: http://www.meetup.com/scrum-12/events/166102122/
- Feb 19, 13
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - AustraliaWednesday, July 30 at 6:00 PM
Attending: 5
Details: http://www.meetup.com/scrum-12/events/148222312/
- Feb 19, 13
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - AustraliaWednesday, August 27 at 6:00 PM
Attending: 2
Details: http://www.meetup.com/scrum-12/events/166390872/
- Jan 09, 14
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - AustraliaWednesday, September 24 at 6:00 PM
Attending: 1
Details: http://www.meetup.com/scrum-12/events/159559552/
-
Posts
- Apr 10, 14
Agile Product Owners and Business Analysts, Melbourne
Here at Redbubble we support a wonderful community of artists around the world by integrating their inspiring designs into unique, customised products.
Artwork: Daydreaming by funkyfacestudio
We also support those people who can't even draw a pair of curtains (like me)! You can create your own style by purchasing T-shirts, phone cases and other cool stuff that will make your friends jealous and ask "Where did you get that?". In doing so you know your hard earned money is supporting the artist that designed your unique product.
Come and learn how we at Redbubble use a combination of Agile Software Development and Lean Startup principles and practices to:
• Deploy fully working and tested software daily, on demand
• Learn about our customers (artists and buyers) by using experimentation, interviews, analytics and metrics
• Deliver MVPs such as rapid prototypes to ensure we are building the right things
As if that wasn't awesome enough, we will even provide pizza and drinks!
See you there!
P.S. If you arrive after 6.30pm you will need to be let in. Please call me (Neil) on 0434 833 963 if that's you :)
Melbourne - AustraliaWednesday, April 30 at 6:00 PM
Attending: 70
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/175460212/
- 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, May 13 at 6:00 PM
Attending: 50
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/146845242/
- 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 people that perform 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. Thinking Skills
• Critical Thinking
• Systems Thinking
• Comfortable Ambiguity
Flexibility
2. Behaviours
• Ask tough questions
• Show, Don't tell
• Influence, not power
• Give the bad news
• Stand up for the value
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, June 10 at 6:00 PM
Attending: 50
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/147672412/
- Jan 07, 14
Agile Product Owners and Business Analysts, Melbourne
Melbourne - Australia
Tuesday, July 8 at 6:00 PM
Attending: 10
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/148222242/
- 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: 18
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: 10
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: 7
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: 7
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: 6
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/159140562/
- 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
- 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 - PresentSenior Engineering Manager / Aconex
- Jul 2013 - PresentChief 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.
- 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
-
1983 - 1988Henry Kendall High School
Additional Information-
Websites:
