Craig Brown

Based in Melbourne. Works across SE Asia.

P: +61412406414
E: craig.brown@craigwbrown.net
T: @Brown_note

Contact
Loading,
0
% complete
  • The Last Retrospective
    Oct 16, 14


    Almost 12 months ago, I wrote a post entitled Installing Scrum, The Hard Way. That post was about the experience of working with a team of people who had accepted the challenge to use an Agile approach to solving a problem of gargantuan proportions, under the most challenging of circumstances. We are now all a year older, many years wiser and have sprinted together 34 times. It is also time for me to say farewell and move on to other opportunities, but before I do there are a few things I would like to put on the record in the form of a thank you note to the team.  



    Dear team,

    Even a year ago, our daily stand ups were still pretty mechanical affairs, our retros were full of uncomfortable silences and presenting our work at review was fraught with anxiety in case something broke. Now we gather each morning to plan the day, we discuss our progress and challenges in full view of the company. Our retros are noisy, robust and result in actionable and actioned outcomes and we present our reviews with confidence; we know nothing will break. Twelve months ago, estimating and planning the sprint was still a 2 day exercise involving spreadsheets and allocating work, now we plan together during the sprint and no one is allocated their work. No one has needed to work back to close a sprint in months and the need to count the hours we will spend is rapidly fading.  We’re in production, delivering shippable product every two weeks and responding to real client feedback in double quick time. 


    This has happened because you have been willing to try to work together in completely new way and to keep trying, no matter what.  You have not stepped, but leapt outside your comfort zone multitudes of times, you never gave up, even when things went horribly wrong.

    Whilst I am sure there are some who could point to our practices and say we’re doing it wrong, that's not Agile, but if any part of Agile is about how people think and work and collaborate to achieve a common goal, I would argue that we’ve done it very very right. The team, the product and the company are unrecognizable when compared to the way things were before.


    Thank you for letting me be part of your amazing story, it has been an honour and a privilege. I have learned so much and have a completely changed view of what is possible. I won’t wish you luck, because it’s not about luck; it’s about effort, commitment and a shared desire to deliver a quality product that has value.    

    I wish you well.






  • Transcendent Purpose
    Oct 06, 14
    You probably know the "What Motivates Us" video; Autonomy, Mastery and Purpose.


    In the engineering team we work hard on building on an existing culture of autonomy and mastery. Great people are given the latitude to tackle interesting challenges the way they feel is best. We have an egalitarian culture where everyone is encouraged to challenge the status quo and push for what they think this the best way forward. We support team members with training opportunities, on the job coaching, conferences, regular actives like retrospectives and the engineering debrief.


    Photo by Tim Norris from Flickr

    The product management team can help elevate engagement and, motivation even further, by helping explain the big fucking deal that is our business proposition.


    Of course everyone buys into this, but are challenged by the how. Where do I get the right stories? What are the right stories? How and when should I share them?



    This academic paper on transcendent purpose is great as it gives a background to why thinking about the big picture is useful. It also gives lots of examples of how different stories and different ways of thinking about sometimes boring) work can be elevated in a way that makes us motivated and engaged in the work in front of us.


    Take a look; Boring but Important: A Self-Transcendent Purpose for Learning Fosters Academic Self-Regulation
  • When have you helped another team?
    Oct 06, 14

    It's all very well getting your own stuff done well and to target, but how often do we stop and ut our own goals aside to help others?

    When have you helped someone on another team? Share your story below in the comments.
  • What parts of your job will get automated first?
    Oct 03, 14
    Picture credit: chiarashine at flikr
    A recent article in the Economist provides more evidence that all-the-workforce is destined to be replaced by technology. What parts of your job will be first to go? And will you be happy to say goodbye to it?
  • How to Prevent Project Failure in 2014
    Sep 18, 14
    Project failure is expensive, embarrassing and alarmingly common. Depending on your estimates - 5%-30% of all projects are successfully completed. Getting to the bottom of project failure is an important way to improve our project performance. If we don't put in the effort to learn, how will we ever make progress?




    Project failure is a problem in every industry and every country. Consider the following statistics.

    I know what you’re thinking. The data above come from surveys that are a few years old. Surely the project management field has made advances. Perhaps new project software and procedures have significantly improved results? Unfortunately, project success remains challenging for most organizations in 2014.


    “Men make history and not the other way around. In periods where there is no leadership, society stands still. Progress occurs when courageous, skillful leaders seize the opportunity to change things for the better.”  - Harry S. Truman, U.S. President


    Recently, I read the PWC report on project management. The PPM 2014 Global Survey draws on the comments from people in 110 countries and more than 3000 respondents – an outstanding global view of project management. Let’s consider the four main failures causes of project failure and what we can do to overcome those problems.


    Poor estimates in the planning phase

    Estimates remain one of the enduring challenges of project management. That makes sense since projects are about change and creating something new. I can estimate travel time in my home city with reasonable accuracy. The first time I visited Lisbon or London, I found it difficult to estimate travel time because it was unfamiliar.


    To improve estimates, the report suggests:
    • Using a multi-step process to validate estimates.
    • Call on the knowledge of subject matter experts (e.g. software developers) to validate estimates

    To those ideas, I would also suggest that project managers should make greater use of their internal network. There is a great deal of project experience that has never been committed to writing. It is up to you to discover this knowledge by building relationships.

    Change(s) in scope mid-project


    In the U.S. Congress, government spending is subject to “pork.” This is the tendency of elected officials to demand additional funds be spent on projects in their areas, even if the projects are of dubious value (e.g. the infamous Gravina Island Bridge “bridge to nowhere” project proposed in Alaska with a +$300 million project).


    At this point, you might be thinking, “oh those foolish politicians.” Think again! How many times have executives, sponsors and other stakeholders undermined a project by adding additional requirements. Unless these requests for additional features are carefully managed, the project will soon collapse under the weight of scope changes.


    PWC’s recommended solution to managing scope creep include the following ideas:

    • Design project plans with flexibility in mind. Built-in flexibility means a change of attitude on scope.
    • Adopt a portfolio approach to projects to discourage tinkering with project scope

    Insufficient resources


    Seeking more responses is the battle cry of many project managers. It is a natural tendency in life to seek out more resources when you feel that you are running out. Unfortunately, organizations are limited in how much budget and staff they can assign to projects. Thoughtful project managers need to find other ways to respond to the challenge of insufficient resources. 
    • Ask other project managers how they solved resource shortages
    • Call in favours from your network, from time to time


    Bio. Bruce Harpham writes about project management training, leadership, productivity and related topics at Project Management Hacks. His project experience includes leading projects in higher education and financial services.

  • Burn down, burn up, then burn down again
    Sep 17, 14

    Over a lunch with some of the guys at work we were talking about generally doing better as a team and things that might help. We drifted into reporting and talked briefly about Burn-up charts and came up with a shared insight.

    Here it is;

    When a team is new to this old agile thing they need some stimulation to reflect and change their approach to work. Small visible deadlines and trajectories of our likelihood to succeed or fail are useful. The burn down chart meets this need. It shows small safe to fail contexts - the sprint and shows whether the team is on track to win or lose at the potentially shippable increment game.



  • How does philosophy shape the way we work?
    Sep 17, 14

    Where we stand shapes our perspective. Our experiences, our journey to this moment are what got us to this perspective. 

    Plato’s cave is an allegory of how our experience limits what we are able to see.


    Rather than explain it to you this video is a great execution and well worth three and a half minutes of your time. Please check it out.

     Our experiences are part of what can shape our perspectives. And our experiences can incorporate the lessons of others.

    We can hear stories of others, and while they may not make sense to start with, we can keep going, exploring more and more ideas – business books, blogs, academic papers, literature, music and art.

    It all adds up to new insights and creativity. Incorporating experiences from outside our natural comfort zones will help us learn more about the world we live in, and get closer to truths.

  • How Successful Project Managers Manage Scarcity
    Sep 08, 14


    Not enough time. Not enough staff. Not enough budget. Such is the lament of project managers around the world. 

    Most of us will face scarcity in some form as we progress through our careers. It is a challenge but one that can be managed with the right perspective. 

    The Psychology of Personal Scarcity.


    When you lack the necessities in life, fear takes over. 

    Your focus rapidly shifts to the short term – finding today’s meal. Thoughts of long term strategies to improve your life fade away. When you’re worried about dinner, it’s difficult to think about retirement savings. It is an uncomfortable place to be. For this discussion, we will assume that your personal needs are not under threat.

    What about the other kinds of scarcity you face in life? Time scarcity is a persistent problem for many professionals (especially those with long commutes to manage). Scarcity of energy and willpower are a second important source of limits. After a tiring day at the office, it’s more difficult to rein in our bad habits on the way home – such as picking up yet another chocolate bar.

    Scarcity does not have to be a project killing challenge. There are strategies for coping with it. In time, you may even come to appreciate the hidden benefits that accrue from scarcity. After all, if you are accustomed to responding to any challenge with “spend more money on it,” your problem solving skills will gradually wither and die.

    Two Ways To Approach Project Scarcity

    The Engineer Approach: Scarcity As Just One More Variable

    Credit: Library of Congress (1939)
    I find that engineers have a very valuable perspective on scarcity. In fact, they use a different word – constraints. Some constraints occur due to physical laws – the melting point of stainless steel for example. Other constraints are manmade – the project’s available pool of skills and staff. Engineers look at constraints as just another factor to include in their plans – there is nothing overwhelming about it.

    We can illustrate the creative ways engineers respond to limits by considering challenges set for engineering students. During their studies, engineers are frequently faced with very limited resources and tight deadlines to deliver projects.

    • The American Society of Mechanical Engineers.The 2014 student challenge involved building a lighter than air Unmanned Air Vehicle (UAV). The challenge included this important constraint: “You cannot purchase and modify an existing commercially available vehicle.” A prohibition on adapting existing equipment acts as a spur to the team’s problem solving capabilities.

    • Canadian Engineering Competition.“Teams are given four hours and are provided with material to construct a solution to the problem and will present and demonstrate their prototype to a panel of judges.” – Canadian Engineering Competition Rules. In this competition, teams of engineering students face two significant challenges – limited time and materials. This dual form of scarcity is an excellent simulation of the limits that project managers face in their daily work.

    • Design/Build/Fly Competition (AIAA).                                                                                         The American Institute of Aeronautics and Astronautics (AIAA) runs an annual contest for students. For the 2013/2014 contest, one third of competing team members must be Junior, Sophomores or Freshmen. In addition, the aircraft is required to use over the counter batteries for power.

    In these three contests, scarcity is an important factor. Interestingly, the competitions also include limitations on team members. 

    Let’s consider the Design/Build/Fly competition rules for a moment. Like other competitions, the AIAA sets restrictions on materials. What sets that contest apart from others is the staff regulation. What if your next project had a requirement to include at least one intern or junior employee? Would you regard that restriction as depriving you of experienced talent? Or would you instead regard that rule as an opportunity to seek new ideas from younger staff?

    You can reframe scarcity on a project. Simply imagine that your project is part of a larger competition. And any competition worth its salt has rules and regulations. Seen in that light, resource scarcity is just another rule.

    The Alternative Uses Solution to Scarcity

    Follow this classic creativity exercise to shift your perspective on scarce resources. Rather than panicking when told about cuts to a project budget, this exercise helps you to focus on what you do have. Consider two examples to help you think about creatively employing your organization’s staff and technology.

    Alternative Uses For Staff

    Staff are the most important aspect of any project. What can a project manager do when faced with scarcity? Look for alternative uses of project staff. Here are some ideas to get you started.
    ·         Project staff connections.

    Informal connections yield valuable insights but only if you explore this idea. Asking your project team about their connections and the possibility of requesting favours can help your project.

    ·         Reviewing Skills.

    In the technology world, many professionals acquire varying levels of skill in many different technologies. A software developer may be best known for his C++ programming skill. At the same time, he may also be knowledgeable about Visual Basic for Applications (VBA).

    When scarcity deprives you of your preferred solution (e.g. a specialized vendor), ask about your team’s skills. In a technology project, you may be able to create a workable solution using VBA or Microsoft Access. Who knows – an improvised solution may yield better results!

    Alternative Uses for Technology

    Many large organizations provide a large suite of applications and other technology to their staff. On any given day, how much of this toolkit do you actually use? Speaking for myself, I generally use only three or four applications per day (Excel, Word and Outlook). By investigating your organization’s technology, you can work around a limited (or non-existent) technology budget.

    ·         Research existing software options.

    Contact your organization’s IT department and ask for a complete list of applications available to you. Some applications will be “free” (i.e. an organization wide license was obtained) and others may have a low cost. A ten or fifteen call to the IT help desk can help you discover plenty of alternative uses for your technology.

    ·         Contact other technology project teams about their technology strategy.

    Does your organization have a project management office (PMO) or other project teams? If so, those groups can act as a resource. Review a list of current and recently completed projects at your organization (including regulatory projects). Once you find a few examples of projects with similar aims, reach out to the project manager and ask how they did it.

    Bio. Bruce Harpham writes about project management training on the Project Management Hacks website. His experience includes leading projects at financial institutions.
  • Let's leverage our Synergies
    Jul 29, 14

    Worth watching :)

  • The thing about Project Management textbooks that drives me nuts the most
    Jul 28, 14
    Work Breakdown Structure (WBS) diagrams are a beautiful tool. They are useful and help manage complex sets of work very well. Watch out though because the textbooks are regularly teaching it wrong.

    Bundle the WBS up with the idea of a backlog and sprints and you have a great way of managing multiple streams of work as well.

    But about 70% Project Management textbooks that I look at are describing a WBS framework incorrectly. No wonder people think so many PM's are pointy haired Dilbert Bosses.


    Let me get specific for you;

    A WBS is doing it wrong if;
    • It focuses on stage gates for a project
      • A WBS that has a top level set of domains like PLAN, ANALYSE, DESIGN, BUILD,  TEST, RELEASE is so so wrong, and this has nothing to do with the agile way of working. It is just plain wrong.
    • It focuses on time boxes as the top level - or any level really - containers.
      • The WBS mainly focuses on the work - the thing to be built. Not the time it takes to build it. That's an effect on sizing the work and comes after figuring out the goals of the customer. 

    From a 2006 blog post. Agile people don't do this any more though.

    A WBS is doing it right if

    • A WBS focuses on customer goals
      • The top level is the overall goal of the customer
      • The next levels are goals and capabilities that trace into that goal
    • A WBS describes tangible things of value to the customer
      • Customers do not care about your activities (or if they do, it's not a part of planning your work.)
      • Customers care about the outcomes and capabilities you will be delivering to them.
      • WBS elements should all be worth the money people spend on them, and thus should stand alone or have clear relationships to how the enable other things of value.
    Comments? Corrections? Let me know.
  • Courage: A workshop idea
    Jul 27, 14
    I ran a workshop at Last Conference this year. I liked this activity as did many people there, so am sharing it here. In the spirit of ship early, ship often; here are some rough notes I used to plan and run the session. 

    Perhaps you can try some of these ideas out (and report back!) Maybe run it as some sort of retrospective activity?

    Intro
    Theory about how we should work is all good and readily accessible, but do we have the courage to drive change? To be the ones that stick out.

    I think about the Nash Equilibrium and how it is rarely to our short term benefit to be the person who challenges the status quo, or the way we do things around here.

    Probably the people that have come to this conference are highly engaged, and leaders in their teams and workplaces. So maybe targeting courage as a thing to build on is not the sweet spot.

    This workshop should aim to give the participants a tool or some ideas that they can take back and use to help others be courageous and successful.
    Method
    We will break into groups and work in three rounds. I will brief you in on each round at it's beginning. Some of this will be a mystery until the right moment.

    Each round is about 5-6 minutes.
     1: Form pairs

    • Activity: Talk about a time you have seen someone be brave or courageous.
    • Debrief: Was that a hard conversation?
    • Appreciation: Thank your partner if there was something in that story that resonated. Be specific of you can.
    Round 2: Pairs, bundle up into groups of 4-6
    • Activity: Talk about a time when you have done something brave (doesn't have to be at work)
    • Debrief: How did it feel? Was it harder or easier to have this talk?
    • Appreciation: (As above)
    Round 3: Each group again merges with the group next to it
    • Part 1: Talk about a time when you have done something particularly brave. Share your feelings about the event with your team. Team can ask questions and explore your story as much as they like.
      • Not everyone will get a chance to tell a story in this round. Just get 2-3 people to share.
    • Part 2: (People think this is the debrief, but...) Ask for three volunteers to stand up and share their story with the whole room. Advise anyone is the room and ask questions and intervene at any time.
      • Three volunteers stand up and tell their stories.
    • Part 3: Thanks to the volunteers. Appreciate their contribution and acknowledge that public speaking, especially when unprepared is a brave thing. Send them back to their seats.
    • Debrief: What do you think about the people who stood up? How did the volunteers feel doing this? What made their act brave? Did you see the escalation of the activities? Each one was harder? How might you use this idea/activity at work?
    • Appreciation: Ask people to thank their team mates and the stand-up volunteers on the way out
    Ideas at play
    • Talking in small groups is easier than large ones
    • Talking about ourselves and how we feel is harder than talking about other people and things
    • We can have smaller conversations to set up bigger ones
    • We can build experience in dealing with hard things (ie Courage) by tackling easier things first
    I think the session was well received. The tweet I did as people got talking got loads of retweets, and I got several thanks in person and via twitter. My favorite bit of feedback was this tweet. (Paul did a similar one but this is the nice hand drawn version.)
  • Thinking about Product Backlogs
    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
    White Hat
    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 Hat
    Uh 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 Hat
    Challenging 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 Hat
    Let'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 Hat
    How 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
  • Six Thinking Hats and Scrum, July 23 Bangalore
    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;

    1. A tool to take back and run with your team that will generate new energy and enthusiasm for improving the way you work 
    2. Through participating in the workshop you will personally gain new insights and ideas about what you can do to help your team improve. 
    I will be applying the six thinking Hats meme to Scrum, as it is a common and known framework for working, but you can apply this to any system of working.

    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.
  • Why scarcity and abundance matter to your business model
    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.

    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?

    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?

  • Tweets
    Tweets
    Profile
  • Posts
    Posts
    Feed
  • Posts
    Posts
    Feed
  • Posts
    Posts
    Feed
  • Info
    Info
    Profile
  • Posts
    Posts
    Feed
    • abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz
    Now Playing
    ×