Better Projects

The end of this blog - August 16th

2021-07-22T09:30:00.004+10:00

Road ends

It's time to pack this blog up and put it away. On 16th August I'll be taking this blog off the internet.

Better Projects started in about August 2005. The first post was "Capturing details about the WBS"

I started this blog as I started a masters' degree at RMIT in Project Management. The course coordinator required us to keep a learning journal thoughout the course. Blogs were relatively new at the time and no no particular reaso I decided to keep my learning journal in public.

Who knows why we take those first steps into the unknown?

There have been 1442 posts including this one. (I have 141 in draft that I never found the time to properly research or write.) The blog has had more than 4 million views over the years. At it's peak it was getting in the order of 130-140k views per month. These days it is still getting 25-30K views a month, which is amazing given how infrequently I post these days.

I am glad the content has been useful.

The blog itself was never about promoting myself or any commercial venture. It emerged at a time where blogging was about people collectively exploring ideas together. It was very much a community of learners. The bloggers themselves were learning in public and generally writing to themselevs or to each other.

Communities are great.

I do feel that age of blogging died with Web2.0 businesses like Facebook, Linkedin and particularly Twitter. At first the commens moved off site, and then eventually the whole conversation. The bogs were still useful. They were a place for personal reflection or to elaborate an idea that was too big for a social media thread. Social media, coupled with an industy of thought leaders promoting their advisory services pushed the original blogging community to the fringes I think.

Entropy seems to be a constant.

During the life of this blog I have met several other bloggers and professionals and built some great and long lasting relationships. BetterProjects has enabled me to crash at people's hourses that I have never met in three different continents, not to mention different cities in Australia. This entertains me to no end.

People are awesome.

Over the years there have been over a dozen guest bloggers and temporary team members who have content published here next to mine. Some I stay in touch with, some are around but in the ether and some I have lost the details for.

To my team mates and blogging colleagues here; Thank you.

My typing (and occaitionally spelling) has always been atrocious, and I rarely went back to correct minor mistakes. Over the years, whether it is my four fingerred typing or the bluetooth keyboards, my typing has steadily gotten worse. Also HTML continues to remind me that two spces after a period is anachronistic.

Sorry for the lack of copy-editing.

What next for this site? I still regularly search for and pull out content that I repurpose when sharing knowledge with others. While some information here is still useful, some is now outdated and it is probably better for me to remove the site over going back and editing or removing posts. I don't have the time or energy. (I suppose the Better Projects tidy up project could support a book project but, at best, that has to wait for another day.) I'll be archiving the blog later in the year. I'll be able to find content, but it will be a private library of content for me.

Goodbye blog in August, the anniversay of the first post.

My time in the immediate future will be focused on growing a great company. If you're interested in Everest Engineering - come check us out at the website. People particularly seem to like the team manifesto - the values and behaviours we try to live by.

Everest Engineering is a company where I get to try to nurture a great culture, and support people to do great work. We are already over 100 strong and continue to grow. Our aspirations as to be, post pandemic, one of the world's most reputable techjnology businesses. We focus on services today and in time will also grow a suite of tools to help others as well.

Wherever Everst takes me I know it's going to be a hell of a ride.

And BetterProjects.net? I also think I will be repurposing this domain name, maybe in 2022 to be focused around "projects for good." I am not sure what form that takes yet, but one idea I have is that people struggle to find the right opportunities to invest thier spare energy. I wonder if I can help with that. We will see.

Anyway, thanks for reading. If you want to stay in touch... I guess Linkedin is the place to do it these days.

16 years isn't bad for a blog. We should throw a party.

Writing Better User Stories

2017-05-01T13:53:00.001+10:00

The patterns of a product owner writing user stories for software development teams is an opportunity to be improved upon.

On Tuesdays at 11am, Mark walks over to the round table near the window. The team see he is ready and wrap up the tasks they are on. Justin heads over to the kitchen and grabs a fresh water. Jerome grabs the two index cards that are still in play from the whiteboard and brings them over to the table as well. Zoltan grabs some sharpies and a stack of post-it notes and walks over with David. They sit around the table.

I walk across and ask if I can sit in and observe the meeting.

Mark plays down six index cards onto the table like a blackjack dealer. Unlike blackjack the cards are all face up with Mark’s almost legible scrawl on them.

Mark picks one of the index cards up and starts reading it to the team. There is a back and forth across the table about why this user story, how does it help the customer, and how it might be implemented. After about 6-7 minutes a consensus is reached and Zoltan grabs the card, flips it over and writes a few acceptance criteria on the back, reading them aloud to the team as he writes. The other software developers on the team chip in with minor adjustments to the phrasing.

By the end of the session, all six cards have been accepted into the sprint and each of Mark’s index cards have also been marked up with the handwriting of the team members on the back.

The guys started to shift, getting ready to get up and head back to their desks to get a little more work done before heading out together for some Korean Fried Chicken (and beer.)

“Hey, before you go, can I ask a couple of questions?”

Everyone settles back into their seats and look at me expectantly.

“It’s interesting to me that each of you on this team have written on the cards. You all took turns to write up the acceptance criteria. Why is that?”

“Well,” says Justin, “If I write the card, then I know what I mean. If someone else writes the card, I have to struggle to remember the details of this conversation and probably have to repeat most of it in three or four days’ time.”

“It’s just easier this way” says Jerome.

“Cool. When did you start doing this?”

“I can’t remember. It just started one day. It didn’t come out of a retro or anything, but we did used to talk about how often we would repeat the user story discussion over a week or fortnight,” said Jerome.

***

There are fundamental reasons why this practice of shared story writing is better than having a product owner or business analyst be the one to exclusively write the user story cards.

Think about your own experience listening to others.

Your attention wanes in and out. You remember parts but not the whole of conversations. And the things that stand out in your memory the most aren’t necessarily the most important things.

However, when you take notes things change. For a start you need to make choices about what to write down. This makes you think about the content in more than one way – you are listening to it, engaging with the idea behind it, thinking about which points you want to focus on in your notes and also choose the words you use to represent the idea. Finally, your body also has to contribute to the note taking. Your hand moves a pen across some paper. Your eyes then read it to confirm what you have written is correct, and then you process the idea again.

All of this is going on almost simultaneously.

As you can see your brain is working much more when taking notes than just listening. This means that the memory around your idea is being imprinted much more firmly in your head than if you had just been listening, or even if you have been engaged in a discussion. You are creating multiple connections in your memory to the idea through these interactions and transaction.

Note taking is a powerful tool when trying to understand and later recall an idea.

(A side note; the act of physically writing appears to be a more powerful tool for understanding and remembering than typing. Even holding an index card improves understanding more than reading a screen because of the same multi-sensory processing going on.)

***

“Nice. Let me ask you another question,” I said. It was almost time to wrap up. The fried chicken was calling. “If this is a good practice, what would make it better?”

The team looked across to Mark, the product owner. A pause. Everyone thought for a moment. One of the guys was chewing his inner cheek as he thought. Zol twirled a pen around his finger. Then David, the team’s designer spoke up.

“We shouldn’t let Mark touch the cards at all.”

Mark was confronted by this idea.

“I don’t feel comfortable with turning up without cards to talk to.”

“That’s okay. You bring your cards, but we will rewrite our own.”

***

There is another opportunity in writing cards rather than receiving them. Can you guess what it is?

Imagine this scenario;

We sit at the table described above. I’m the product owner and I hand you a card with my user story on it. I tell you what the customer goal is, their motivations, the constraints and related rules around the user story. You listen attentively. It seems kind of obvious. You ask one or two questions about what I explain.

At the end of this discussion, because I am diligent I ask you; “Do you understand what needs to be done?”

You give a short nod affirming you understanding and head off to do the work.

That sounds straightforward and simple, right?

Now imagine this scenario.

Same job, but this time I hand you a pen and paper and you write the notes. I still tell you the same things but this time you are actively asking questions and drilling into what I am saying because you are writing notes down. You choose the description. You use your own mental models to frame the written description. And at the end you say what you understand the job to be, by reading out what’s on the card.

Which of these two scenarios is going to better equip you to go away and do the work?

***

Mark and the team tried the experiment and it was useful for a while. Over time they vacillated between Mark writing cards and the team writing the cards. They are a tight knit group and these days anyone writes whatever needs writing regardless of role.

There was one last effect I saw as they played this out, and it isn’t specific to the technique. It’s more about the people; By putting the card writing in the hands of the delivery team it put responsibility into their hands to pointedly and specifically ask “What’s in this for the customer.” Over and over again they guys asked that question. They were always very customer centric, but they were no longer being told. They were actively asking. That helped the knowledge acquisition and it helped memory and focus. It also helped with prioritization and managing scope better.

***

It’s funny. People like to find patterns and follow them. Inherent in high performing teams is the need to go farther and do better. The job isn’t done when you have your requirements on a pin-board and can ship features fortnightly. You don’t follow a manual.

The fundamental thing about this agile movement is learning through doing. You inspect and adapt. You ship and get feedback. You collaborate, deliver, reflect, and improve. You explore and learn. And that means experimenting and researching.

The scientific theory behind these ideas idea is pretty well established, although there is debate about how to make the most impact for memory. And it’s intuitively true to most people when you describe the ask over tell mode of communicating. Most people just get it. Still, people don’t change their habits without expending their limited energy.

To help you shift I want to ease you in with a low-cost experiment.

Share this post with your team mates and talk about it together. Propose that you all run the new card dynamic as an experiment in your next sprint. If your Product Owner is currently writing ALL the cards, maybe take the first step of just taking over acceptance criteria. But why stop there. It’s an experiment. You could just take over the whole card writing thing and give it a shot.

Then, at the end of each week, maybe for two sprints, talk about whether the new card dynamic has paid off in any ways.

***

Here are some links to more on this topic in case you want to go deeper.

Some details of this anecdote have been simplified to make the point, but this is a real case study with a real team.

As always I love to hear feedback if you try any of my ideas out. Comment below, tell me direct etc.

Thanks for reading.

Well, here we are.

2016-10-25T23:55:00.002+11:00

How many people have done agile training in Australia?

2016-10-11T23:30:00.000+11:00

I was wondering this in the context of another problem. And this is what I came up with.

I went to Scrum Alliance to see how many certified scrum people there are in Australia. Their search gave me a hundred pages of ten people per page. That’s 10,000 certified scrummers. (CSM, CPO, CSP, etc)

I checked to see if I was there, having done my CSM in about 2010. Nope, so it is only people who maintain currency.

The Scrum.org numbers. Not available, but let’s imagine a pareto rule applies and they have 2000 current registered certifications.

I imagine that investing in the certification comes with the training and 80+% of people let it lapse within 1-2 years. This Scrum thing has been a big deal for about ten yours now in Australia, so potentially the market is reasonably saturated and growth is maybe 10% year on year.

So maybe there are about 12,000 people currently registered, and maybe 40,000 people have been through some sort of certified scrum training.

Let’s imagine another class or corporate agile training that touches a few, but essentially washes over the heads of many. Let’s say another 100,000 because enterprise IT is big.

That hints that there are about 150,000 people who have been in a classroom doing some kind of agile training.

Does that feel right?

What’s a model for?

2016-10-04T19:11:00.001+11:00

I saw a tweet about a model called Burndown which defined itself as a solution to the shortcomings of agile development. A friend lamented that they’re disassociating from the Agile movement because of the ‘crappy agile’ idea.

I had planned on writing up a similar post internally where I work but think I’ll also publish it publically. My motivation isn’t to shame agile, but to show how it can evolve and provide another example off the beaten track of the normal consulting frameworks.

Not that consultant frameworks are bad by the way. I’m currently browsing the SAFE book with the intent of cherry picking out some good ideas and presenting them as options or tools for teams to draw on.

But this discussion of new frameworks like Burndown also raises another interesting question for me; How do we assess the usefulness and validity of frameworks and models?

One way, which I might try with some components from SAFE is to present them as small and low risk options to experiment with, another more common path is to execute on an “Agile Transformation.”

There are strengths and weaknesses to both of these approaches, but there is also still a need to objective evaluation of their usefulness, both before and after trying the tools they describe.

So a simple way to evaluate these models is a SWOT analysis.

But is a SWOT analysis the right tool for the job? How do you know you’ve picked the right model?

Agile will never work here

2016-09-14T06:00:00.000+10:00

TL/DR: Agile will never work in Asia, America, Argentina Australia, China, India, or anywhere, really.

Scrum does not work in Asia.
Why not?

A hierarchy culture where people do what they are told by their boss
People value harmony over disruption and so disupting the way things are is frowned upon
There is a deeply rooted deference to authority and conformity
Most of the work is based in the outsourcing industry and has a cost focus. Quality, innovation and agility are not valued.

5 reasons why agile won't work in Germany
Why not?

Deference to heirarchy is a very strong aspect to the national culture
The whole society is structured into silos. Focus on your job and do it well, rather thank think about the broader picture
Germans love planning, and so let's focus on planning.
Germans love perfection. Iterating on an imperfect implementation drives us nuts.
We have a conservative culture and don't want to rock the boat.

Why Agile won't work in Argentina
Why not?

Entreprenuers and managers make decicions based in short term horizons
Becasue we only care about the immediate future, the cost of quality feels to high
We have a service industry (like Asia) and so project cost is more important than longer term sustainability
Our culture celebrates heroes, so we value individual contributions over team culture
Heroes get rewarded. Also, our pride and ego put our individual identity ahead of our team

There are more. And not just regions, but industries also. I bet we can find posts on why Agile doesn't work in banks, startups, R&D projects, government, etc.

I'd love you guys to post links to the comments and help expand this list.

Is there an antidote to these problems? Maybe

“Cognitive bias cheat sheet” @buster

2016-09-06T07:09:00.000+10:00

The now famous List of Cognitive Biases on Wikipedia is now getting ugly and cluttered.

Fortunately this guy has written a better description and organising of the biases. He frames the long list of duplicated and marginally specific biases by the problems they solve. Of course this description is subject to a framing bias, but it does seem to work as a sense making model.

Do take a look.

“Cognitive bias cheat sheet” @buster https://betterhumans.coach.me/cognitive-bias-cheat-sheet-55a472476b18

Book Review: The Heretic’s Guide to Management

2016-09-04T16:45:00.000+10:00

The Heretic's Guide To Management: The Art of Harnessing Ambiguity by Paul Culmsee
My rating: 5 of 5 stars

TL/DR - It’s a great, entertaining book on managing people in a complex world. Buy it and read it today.

I am really happy Paul and Kailash wrote a follow up to their 2011 book The Heretic's’ Guide to Best Practices. That was a book with great storytelling weaving together 50 years of management academia.

It told the story of how work is inherently complex and you can’t just treat it like a game with a simple rule book. They showed how and why the simplistic approach to work of best practices is antithetical to actually doing good work together.

I read that Heretic’s guide enjoying the book as a bringing together and sorting of a bunch of ideas I was already familiar with. They created a great reference book showing the history of good and bad management ideas that I could point people at. It encapsulated for me years of learning that I had acquired through research, conservation and study. Now it was much easier to get people to read the book and they could catch up in hours or days.

Amusingly, at the end of the Best Practices book they broke the promise of the title in a way typical of both their larrikin senses of humour. They shared a best practice with us for dealing with complex social systems. (I won’t share it here. Read the book.)

This new book is also a good read. It’s full of humour and anecdotes, but is backed with an oblique and deep academic pedigree. Kailash and Paul know how to look beyond the business bestseller list when they research. They follow the academics and they check the academic theory against their own extensive experiences. This adds up to a well researched and entertaining story that you know you can work with.

Once again this book kicks off with a sharp and pointed criticism of best practices, this time in the guise of management models. They show how you can quickly establish your own management framework in four easy steps. This is done tongue firmly in cheek to arouse your natural skepticism about snake-oil dealers peddling certification schemes.

(As if YOU would be suckered, dear reader. You’re one of the smart ones.)

Having you in on the joke, they then proceed to take you on a tour of how our brains manipulate us when we aren’t expecting it; name-checking lists of cognitive biases, provoking us with statements designed to generate an emotional response in you to what they write, until eventually settling down and getting to the heart of this book's idea.

The big idea of this book is about how we deal with uncertainty and the middle section spends quite a bit of time addressing how you and I handle ambiguity. It's compelling stuff and it resonates.

But so what? Is this just another book about complexity? Interesting but of what practical value? Kailash and Paul are all about the pay-off. The author's solution is to recommend we managers use ambiguity to our advantage, even if we don’t always embrace it with love in our hearts.

The last part of the book then follows the precedent of it’s predecessor and ironically provides us with a management supermodel that provides tools for managing (manipulating) people at work by amplifying or diminishing ambiguity.

Once again, the book is an excellent read. It is more engaging and fun to read than many other business books. Both the authors have a perverse sense of humour. Both are deeply skeptical of the fads of the management consulting industry and both are great storytellers. As with the first book I now have a concise repository of a number of important and useful ideas that I can refer people to.

In fact, I like this book better than the first (and I liked the first a lot.) This one is shorter, more to the point, and funnier.

When I read this book I instantly wanted to get a handful of my friends and colleagues to go buy it, and I have bought a couple of copies for people. I highly recommend you go buy it and read it also.

Now.

View all my reviews

I deeply deeply care, but frankly...

2016-07-13T03:58:00.000+10:00

I've been running this meetup group for over five years. I organise content, speakers and venues. People get fed a steady diet of instructive experiences that help them grow as professionals.

But sometimes I get busy and sometimes I can't pull it together. For two years I have run a series of activities designed to attract and install a backup collection of people (alternatives to me) in this meetup community. And I have failed to build redundancy to my key man role.

Some people would find that rewarding; that they are important to the continued existence of a community. Me? I find it annoying.

I am not that special. Anyone could do what I do. It is not technically hard. All it requires is caring about others. And a small bit of admin time.

And so this community degrades because others fail to step in to the awaiting leadership roles.

Fuck you people. Lift your goddamm game.

No wonder workplaces are so full of mediocrity. It's you guys being mediocre.

5 Reasons Why Projects are an Essential Tool for Better Business

2016-06-26T17:03:00.000+10:00

Click this image to get a PDF booklet on
the argument for #NoProjects

This article is an inoculation against the #NoProjects meme.

Projects are great. Despite the cry on the web about projects being bad for business they can really help you do a better job of organizing your work.

I am writing this as a counter to a meme about why projects are evil and need to be abolished. What was once a sentiment is now a movement (with it's own hashtag, so it really is legit.)

The main arguments against projects seem to be;

Projects are temporary organisations. People that work on projects don't have to live with the consequences of the work they do, and so will eagerly take quality shortcuts that someone else is going to have to pay for
Projects are organised around impossible goals. Some executive somewhere wants a new product out to market, or internal process fixed and all the big decisions about time money and scope are done before you arrive.

There are more, but they are essentially minor next to these two complaints.

So, drumroll please.

A note on the 5th LAST conference (that you should go to)

2016-06-16T07:59:00.002+10:00

LAST Conference is in it's 5th year and we happen to be the largest Agile Conference in Australia. We have about 150 speakers and about 160 sessions over two days. We do all this for the price of a fancy lunch. Which is relevant because we provide three meals and a bar tab at the end of the day.

Over the years Ed and I have run LAST Conference as a conference we would want to go to. It's a little bit chaotic, it's fun, it's overstuffed with ideas. This year we have tried a few variations on what we have done before. Here they are for posterity and with some comments on how we are going;

There is a tech conference woven in among the Lean-Agile stuff
Code retreat is embedded in the bigger conference
We have expanded the team who program the content
LAST is over 2 days this year

Let me elaborate on these;

The hidden tech conference
To see the tech talks you can browse the program by topic. I have also added a LAST|Tech Twitter handle to several of the specifically tech talks. See here for the list of tech sessions.

Each year I look for something beyond the 'agile mainstream,' because, basically I want some content that I will be stimulated by and most of the agile stuff, well, I want something more. And I suspect a bunch of other people do also.

This year I focused my attentions on a stronger technical program. We have always had tech talks but the audiences for them have been a bit lukewarm. Build it and maybe they'll come.

My motivation here: If LAST doesn't maintain interest from software developers it will eventually fail as a cross-discipline event. If it fails as a cross discipline (aka whole team) event, then it will not be loving up to some of my aspirations for it.

So, borderline tech people, go to the tech talks to help entrench them into the program. Tech people, go along to LAST and enjoy the tech talks.

Code retreat
I work with Supriya Joshi who is very passionate about the software development community of practice. One of the events she is active in is Code Retreat. I asked her if we could put Code retreat into LAST this year. It's an experiment and we will see how the two fit together.

Code retreat is a place for people to come and get some structured coaching on theor coding skills. It's accessible and friendly.

The expanded team
Our core team is still Ed, Paul and me. Additionally this year we invited Rajesh Mathur, Ryan McKergow, Kelsey Van Haaster, Victoria Schiffer and Steven Mitchell to help program the content.

Expanding the team expanded the work for me, but the value it brings is important. We get a wider view of what content we should be programming. We broaden our perspective beyond "What Craig reckons." And we increase our network of ideas and experiences.

You can see the results I think. The line-up this year is stronger than ever before. There is diversity in thoughts, ideas and experiences and coherence around values.

2 days of conference goodness
Our main feedback over the years has been too much content drives people nuts. So we are running the event over two days with a number of sessions repeated on both days. A big thank you to speakers who have donated their time to do this. As a punter coming along, you cna choose to come both days or just one.

This conference is essentially about a community of practice coming together to share ideas and experiences and to learn from each other. Come along and share yours with us.

Webinar: Project Portfolio Management

2016-06-16T06:22:00.001+10:00

Once I was asked to audit a portfolio of projects in a large IT organization. I asked the project managers, the dev managers, test leads, the business analysts and the business sponsors and stakeholders what they were looking for from their IT projects and how they felt the project was going.

One thing that came from that was a realization that people in different roles have different ideas about what success looks like. And this view shifts people expectations and behaviors. When I had done with the audit I don't know if I found a single project with everyone aligned on the goals, let alone views on how the project was doing.

From that point on I have kept my eyes and ears open to this risk. I have found it to be pervasive in what I'll call "process oriented' companies.

As the years went on I found myself running project portfolios, and setting up portfolio management systems. I ended up with more than one portfolio management book on my bookshelf. I was even sent a PMO book with a note of thanks from the authors for some of the ideas shared on this blog.

I am still in some ways managing project portfolios today, and I remain focused on shared understanding of goals as one of, if not THE most important thing to attend to. This alone is not a trivial task.

Yesterday I was contacted by Isidora from a PMO oriented start-up called ITM Platform and she asked me to promote a webinar they are running. She referenced Kanban in her pitch, which makes it interesting to me. It's on at a time I will not be able to make. Maybe I'll check for a recorded version later. Maybe you can help and drop comments here.

Here is the promotion

FREE WEBINAR with ITM PLATFORM: Set up a Project Portfolio Management Organization.
ITM Platform has implemented our project management solution in over 300 organizations. And want to share the lessons they have learned with you to help you develop and improve your project-oriented organization.
What you will see during 45 min?

Design of a project-driven organization.
Change Management.
Basic Configuration of ITM Platform.

When? JUNE 16th at 10 am (Boston, Eastern Tine Zone)
How to register? Click Here: https://attendee.gotowebinar.com/regist…/9108160085963125507

If you register I will perhaps get $1. So I have a big incentive to get you to sign up. What I would prefer is that you guys pass back what you learn in the comments. If you do that I'll donate their payment to a charity that my sister recommends.

Tips for being a better listener

2016-06-02T09:15:00.000+10:00

We all know we should be better listeners. This School of Life video gives 5 specific things we can focus on to improve.

We are changing LAST Conference this year: Here is how and why.

2016-05-29T10:31:00.001+10:00

TL/DR: We are making changes to LAST Conference to improve the attendee experience. Go check out the sessions you want to go visit on Lanyrd. And then go buy a ticket before they sell out.

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

I heartily endorse this belief. I have been organizing it with my friend Ed Wong since 2011 and we think we have got a pretty good set up going.

We ask people what they thought of each event a week or so later, and the huge numbers of actual responses, plus the very overwhelmingly positive comments we hear reassure us our initial design ideas were right. We have also been written up by several industry folks unilaterally declaring our event to be amazing.

We hear that people love the community vibe, the low fuss, non-corporate feel of the event. We hear things like our instructions to "vote with your feet" on sessions empowers people to explore and bail on sessions if they aren't useful or fit for the audience member. And the rich variety of sessions; games, workshops, talks make for a great day. Plus meals and a drinks tab at the local pub that pull people together and provide a place to talk and exchange ideas with co-attendees.

We have done all this for less than $100 a ticket, because when we originally set this conference up we were looking to help people at not-for-profits, government agencies, small businesses and startups who didn't have the budget to go to expensive training events and conferences.

Despite all this, we get some complaints.

The most frequent issue reported to us is that the volume of sessions on one day mean that people get frustrated with the choices they have to make and the opportunity cost of going to one session over another.

Scarcity equals value, right?

We have a huge number of speakers and facilitators with lots of concurrent things going on. We charge the equivalent of an expensive lunch for a ticket. So don't we need to make something scarce? We designed the choke point to be the attendee's time. AT first we though that was a good idea - people will just have to come along to the meetups in town, and come back next year for another event.

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

We have spread the conference over two days and we have asked a number of speakers to come back and repeat their session from the Thursday on Friday. Not everyone could afford the time, and sometimes we have swapped out speakers but hung onto the same topic.

We also have (as of the day I publish this blog post) MOST of the sessions published on Lanyrd, which means you can browse through what's on and think about what you want to track and go see. Check out the handy features on the Lanyrd page that help you plan your event.

So head along, enjoy yourself, and let me and Ed know how you think the conference is doing.

#EdWongisSexy

Put your damn photo on your work tool profiles.

2016-05-12T14:26:00.002+10:00

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

Put your photo on your profiles.

Right now we are more globally dispersed than ever before, and people on opposite sides of the world have had very little interaction or chances to get to know each other. That will change over time, but we’ll also continue to grow and recruit new team members. Managing connected-ness over distance is becoming an increasingly important competence for more and more of our team members.

To increase our ability to collaborate, to work together and be one great team, we need to overcome the impediments that distance puts between us.

Distance presents all sorts of collaboration challenges; time differences, lags in back and forth communication and a variety of other things that slow the transfer of information from person to person.

Distance also stops us from even considering communicating. There is something called the Allen curve, which is backed up by repeated experiments over time that shows that essentially Out of Site equals Out of Mind. If we can’t see you we typically don’t think about you.

Photos on your Slack or Intranet profile won’t make a huge difference to this, but it will help people in other buildings recognise you and know who you are, and think about you as a human being rather than just a faceless name from another place. This combined with other interactions and activities will gently contribute to trust across the geographical divides.

So put your photo on your Confluence, Slack and other profiles.

Yeah, but no.

If we do nothing to address trust people will start wondering “What’s he building in there?” There will be suspicion, uncertainty, doubt and ultimately fear. And we all know where that leads us…

So, a photo is a little thing, but it helps. It’s absence hurts.

Tips for a good profile pic.

Here are some tips to do the picture thing well.

Use a photo of yourself. Photos humanize the name from another place. They help people who are travelling recognize you when they walk for the first time into your building. Using a cartoon character, an image from the internet, or a photo of someone else might be amusing, but they don’t contribute to trust, recognition and understanding.

Use a recent image. That picture of me from 2001 isn’t really going to help people recognize me when I walk into their office for the first time next week.

Make it a headshot. Headshots are best - profile photos are small. Don’t make it hard for people to recognise you from the photo.

Make eye contact with the camera. People will be able to look right at you and recognize you when they walk for the first time into your office. Don’t have that photo? Close approximation will probably do.

Smile, Damn it. Look friendly and approachable. Smiling is a smart option. After all, it’s trust we are working on here.

Don’t worry about perfect. Good enough is making a small effort. It shows you care. It shows you have taken a few moments to do something for others. That’s a great step.

Thank you.

Now go upload your profile picture.

Heart of Agile talk by Alistair Cockburn

2016-04-14T14:08:00.002+10:00

We recently had Alistair come to the office and give a talk.

The Heart of Agile is a fresh look at Agile that strips away a lot f the cruft that has built up over recent years. This video is interesting and useful.

It goes for about 50 minutes so find yourself some time and a nice quiet place and sit down and listen.

Here it is...

Am I doing a good job? Some tips on getting feedback.

2016-03-11T10:39:00.001+11:00

Maybe you have a performance review coming up? Maybe you want to work as part of a community of practice to improve your game?

Where do you look for tips and advice?

Blogs with discussions on how a role should be played? These will be useful data points but are based upon someone else's experience. It's valuable. But only so much as asking an experience person who has never stepped into your office and met you team or customers.

Consultants with frameworks that look across organisations? Useful to see what the industry is doing, and you may get some good tips. But following consultant frameworks is a recipe for regression to the mean. It's useful if you are a low performing organisation, but if you are better than average, do you really want to shift your performance towards the middle?

Potentially the best place to get feedback (and many people are going to say 'of course!') is your own local context.

Here is a quick map of some places you could get ideas. All you need to do is make time and go ask a few people how things are going in relation to your work.

59 Topics for an Agile meetup

2016-01-27T10:24:00.001+11:00

In case you were running dry on topics...

I scouted the various meetup groups around the world, asked a few people and added some myself.

Scrum and legacy systems
Program Portfolio management
Application Architecture and impact on velocity
Individuals and Interactions over Process and tools
User Experience and Scrum
Business Value – what does it mean to you?
Handling Tech debt
Who owns quality, and what do they say about our work?
Hyper-productivity – breaking the rules
Scrum in operations/support
Coaching dojo
Enterprise architecture – finding the balance of planned and emergent design
Strategic product ownership
Managing managers
Planning poker and other estimation techniques
Training new scrum teams
Self organising
Continuous Integration, Continuous delivery
Agile Testing
Acceptance Testing: Just say no (James Shore’s thinking)
Collective ownership
Agile tools
PMI-Agile combo
Requirements decomposition – epic to story
Release planning
Story mapping
Evidence based Retrospectives
Innovation Games
Roadmaps
Lean Startup and Agile
Estimating, Velocity, and Charts
Can Six Sigma help scrum teams?
TDD
Definition of Done
Scrum Certifications & what they mean,
Failed scrum implementations
What we can learn from the punks and hippies; lessons from change agents of decades past
Scrum beyond Development
Selling Scrum to senior management
Offshore teams and scrum
Dan Pink’s Mastery, Autonomy and Purpose
Hybrid Agile; Friend of foe?
Management 3.0
Memetics – why easy ideas are stickier than good ones. What does this mean in the world of scrum?
Deeper look at the Agile Manifesto
Open forum with experts
Complexity theory
Shu-Ha-Ri-Kokoro
Heart of Agile
The Philosophy of Work; what modern philosophy has to say about the way we work
What is Lean and Kanban
XP and Scrum combo
The missing Parts of Scrum
Agile contracts, Agile proposals
When to leave scrum behind
Revisiting scrum roles; There are no project managers, no business analysts, no testers and no developers.
What Theory of Constraints can teach us
Startups and Scrum
Scrum v Kanban/Lean

Donate to Wikimedia now.

2015-12-18T10:17:00.002+11:00

We all owe Wikimedia for the great service they provide in Wikipedia. I donated today, as I do each year.

Your turn.

A Thin Slice of Value

2015-10-24T16:27:00.001+11:00

The very first principle of the Agile Manifesto reads:

“Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.”

I’m reasonably sure that most people (business, technical and customers) would agree that as a principle this is sound and that we should indeed seek ways to identify and deliver value as early as possible in any development (software or other) initiative. The principle however, only gets us so far, it makes what we want to do clear enough but doesn’t help much with how to actually do it.

This post addresses the how by providing a step-by-step guide to one approach to finding the earliest and best possible slice of deliverable value. The approach is called Blitz Planning and is introduced and covered in detail in Alistair Cockburn’s Crystal Clear [1]. Blitz Planning is applicable in a wide range of contexts, from software development through to business process change.

Re-Introducing Blitz Planning – Setting the scene

Firstly it’s important to understand that Blitz planning is not about generating user stories or identifying epics and features; although it is likely to provide an input to some of these things if used in this context. The output of a Blitz planning activity can inform your release plan however, the key objective of blitz planning is to find the earliest possible point at which business value (revenue or savings) can be delivered.

I like to run this activity as part of an inception, which is the multi-day planning workshop used to kick off a new or re-imagined project, initiative or other piece of work. You can read more about inceptions here and here. It makes most sense to conduct your Blitz Planning exercise before you start to identify epics or features and while you are still working at a fairly high level.

It’s critical to have all the right people in the room. This means the representatives of all the stakeholder groups who will be impacted by, or who will have an interest in your project. This should include; technical people, business people (including your executive sponsor), process people and if possible your customer (the end user of your product) or their (knowledgeable) representative.

To conduct the exercise you need index cards, stickies, builders tape, sharpies and a large table or floor space. It’s important to be able to easily move the cards around.

Getting Started

Step 1; what are all the things we need to do to deliver this project?

Ask your participants to form affinity groups, by this I mean groups of shared interest, for example you might have, a technical group, made up of developers, QA’s, BA’s and infrastructure/operations folk. Another group may be made up of business representatives, marketing team members and perhaps your project sponsor. If you have end user/customer representatives in the room, they might form a team with training and communications experts.

Ask each team to brainstorm and then write cards for every task which needs to be done. This should include all kinds of tasks, but not processes; for example, "migrate database" or "order hardware", are tasks, whereas "run a showcase", or "run an elaboration workshop" are not. Don’t worry too much about granularity at this point; you will get a chance to review that shortly.

Step 2; where are the dependencies?

Ask each team to group their cards by theme (for example; all the infrastructure tasks form a theme) and lay them out in vertical columns on the table or floor. The tasks should be ordered by dependency in each column, any task which is independent or can be done in parallel with another should be in it’s own column. You will end up with something that looks like this.

Review what you have; at this point, you will likely find some duplicates between the teams; these cards can be stacked on top of one another. You may also identify some tasks that are too large and have multiple dependent parts, break these out until you have only single columns of discreet but related tasks.

Ask each team to review the other teams columns of tasks looking for duplicates, and omissions, merging and refining columns as they work.

Step 3; Creating a big picture

Now bring together all the columns of tasks from the teams, placing them on the table, but leaving a decent amount of space above your cards when viewed from the bottom to top. Align all the columns horizontally in order of any obvious dependencies, for example you may want to take into account any long lead times, such as regulatory approvals or print material runs. Don’t worry too much about these though; they are not critical at this point.

You will now have something that looks a bit like a walking skeleton or story map but is not made up of stories but of all the tasks that need to be done for the project.

Step 4; Estimate and Tag

In this step ask participants with relevant knowledge to tag each card with a high level estimate of how long they think the task will take to complete. These estimates should be given in days, are intended to be very rough and should be based on total elapsed time. These estimates are designed to give the team a general feel for the size of the project, nothing more, so don’t get too prescriptive, err on the side of generosity. Where there are a number of wildly differing estimates on a task, take the opportunity to explore the differences and come up with an agreed best guess.

Tag each card with an indicator of who or which team needs to do it. If a particular person with specific expertise is required mark this on the card too. The objective of this step is to identify key constraints such as a significant amount of work dependent on one individual or team. This should lead to discussion on how this might be avoided and presents an opportunity to think about how you might apply techniques such as the 5 focussing steps from the Theory of Constraints [2], [3]

Step 5; Review dependencies

Now bring your teams together and take some time to review your cards again as a group. Particular cards may trigger ideas for more cards. Question all dependencies, you may find that some things that have been identified as dependencies could in fact be done in parallel. You should also identify and tag any very strict dependencies that exist. An example of a strict dependency might be that you need to develop training materials before you can deliver them.

Step 6 Make magic happen

Now grab your builder’s tape and create a horizontal line above your top row of cards but leaving space at the top of the table. Look at your columns of cards and ask, what tasks do we absolutely need to do to prove this concept. You are looking for the thinnest possible end-to-end slice of functionality. Move these cards above your line to the top of the table. Look for opportunities to make this as fast and a lightweight as possible. Consider options such as not using the end state architecture. Perhaps you decide that you can use a flat file to hold data rather than a database. Make sure you have included any tasks which are not part of the development process, but which need to be done first, such as obtaining software licences, or spiking out a technical challenge. This first cut may not be useable in a production sense, but should prove your concept. This is particularly valuable where your project requires you to integrate several systems.

Place a second line of tape beneath these cards; you should have a gap between the line of tape and the top of your remaining columns of cards. Move cards to make this space if you need to. Now place the cards that are absolutely needed to create a product that someone can use below this second line of tape. This is your MVP; its purpose is to allow you to get early feedback on your product and is an important potential pivot point for the business.

Place a third line of tape beneath your MVP and add the cards that would be needed to create a product that generates the earliest possible business value. This may take the form of earned revenue or savings. This step may trigger discussions about how business value can be measured and may also result in the generation of more cards around identifying appropriate metrics. If this is the case, estimate and tag these cards and place them appropriately.

Now add up the estimates in each column for each of your releases. Then add these horizontally.

At this point, both the team and your sponsor have enormous early visibility over the project, its size scope and complexity. This can lead to a number of important discussions about how valuable a project actually is and how much needs to be included to deliver sufficient value. The team and the sponsor may be either pleasantly or unpleasantly surprised by results but everyone will probably be appreciative of the level of transparency and the shared understanding they now have.

Step 7 Identify further releases and mitigate risks

Assuming that your project sponsor has not decided that the whole project is now a bad idea, you can go on to identify further releases. These can be represented by clusters of functionality that add additional business value, so you may decide to move these up to an earlier release, or you may decide to delay a cluster which does not appear to add sufficient value. You may also spot cards that carry a large amount of risk late in the project, especially if they are tasks that could be very expensive if they go wrong. You can discuss how to mitigate these risks by looking for opportunities to start these as early as possible.

Conclusion

Having used this technique several times now I have found it to be very worthwhile from a number of different perspectives.

· It provides you with the high-level planning equivalent of a user story card. (In the same way that a story card is not a requirement but a placeholder for a conversation, the potential releases you have identified are placeholders for further conversation.) You can take each one of these forwards to use as a starting point for more detailed release planning activities.

· Both business and technical stakeholders have a shared understanding and level of visibility over the project. This leads to more valuable conversations and the minimisation of the tensions between technology and business that can sometimes emerge, even in the most enlightened organisations.

· The approach forces everyone to focus on delivering the most valuable software for the customer as early as possible and on measuring that value.

This post has been my interpretation of how to conduct and use this technique, if you would like to read a more detailed description of its origins and use you should buy and read Crystal Clear or attend an Advanced Agile Master Class where it is taught by it’s inventor, Alistair Cockburn.

References

[1] A. Cockburn, Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley, 2008.

[2] “Theory of Constraints.” [Online]. Available: http://www.leanproduction.com/theory-of-constraints.html. [Accessed: 24-Oct-2015].

[3] M. Naor, E. S. Bernardes, and A. Coman, “Theory of constraints: is it a theory and a good one?,” Int. J. Prod. Res., vol. 51, no. 2, pp. 542–554, Jan. 2013.

Frameworks for Scaling Agility; A Cautionary Tale

2015-08-11T07:42:00.001+10:00

By Kelsey van Haaster

Note: This post was originally published on LinkedIn

In his seminal paper entitled “Agility from first principles: Reconstructing the concept of Agility in ISD” [1] Kieran Conboy offers the following as a definition of Agility;

“…the continual readiness of an ISD method to rapidly or inherently create change, proactively or reactively embrace change, and learn from change which contributing to perceived customer value (economy, quality and simplicity) through its collective components and relationships with its environment.”

Conboy’s definition was created in the context of an evaluation of the efficacy of specific software development practices; it is based on a careful analysis of the terms Agile and Lean and is grounded by research into the history, principles and practices associated with them over the last several decades. Conboy carefully documents the process through which the definition is arrived at, such that it is repeatable independent and trustworthy.

If you replace the words ISD method, with organisation and scale it to an organisational level it aligns quite nicely with the idea of responding to digital disruption a term used to describe

“…changes enabled by digital technologies that occur at a pace and magnitude that disrupt established ways of value creation, social interactions, doing business and more generally our thinking.” [2]

In other words, in order to respond to digital disruption organisations perceive that they need Agility.

Given the urgent calls for businesses to embrace the concept of digital disruption from organisations such as the Reserve Bank of Australia [3] amongst others; as well as the somewhat dismal figures for the success of technology projects in general [4] it should not be at all surprising that Agile and Lean approaches to doing business are currently of great interest to organisations working with digital technology. This means that more and more businesses are asking how they can use Agility to leverage the perceived benefits of digital disruption within their organisations.

However, organisations which have attempted to introduce or to scale Agile, have learned that the implications of adopting Agility are far broader than just replicating the approaches and activities that have been successful for individual teams. Adopting Agility at an enterprise level implies a significant cultural and organisational change. This kind of change impacts roles and responsibilities, corporate governance mechanisms, reporting mechanisms, approaches to corporate and financial planning, marketing, sales forecasting and public relations; as well as demanding new and different conversations with stakeholders, shareholders and the user community.

More than a decade of research into Agility has resulted in a substantial body of literature highlighting these challenges as well as the practical difficulties of scaling Agile in-the-large, which include; managing variability amongst team processes, lifecycles and approaches to developing and managing requirements [5], [6], [7], [8], [9], [10], [11]. Whilst a number of high profile digital organisations have successfully adopted Agile as whole of business approach [12], [13], these success stories are not the majority. So whilst corporate interest continues to grow, so do concerns about the risks and challenges implicit in attempting to initiate such broad corporate change. Consequentially, organisational governance teams are seeking assurances about the potential costs and benefits of making these kinds of changes [14] .

Enter the Frameworks for Agile in-the-large

In response to these concerns a number of frameworks offering a pathway to Agile-in-the-large have emerged; some examples of which are DaD (Disciplined Agile Delivery), [15], and more recently, LeSS, (Large Scale Scrum) [16], and SAFe (Scaled Agile Framework)[17].

LeSS (Large Scale Scrum) championed by author Craig Larman, [15] proposes adding just enough extra structure to the existing Scrum framework to better support scaling to more than one team. LeSS does not add new concepts, rituals or artefacts to Scrum but proposes an approach to applying existing ideas to larger groups with the primary objective of improving communication. LeSS offers a certification scheme and a range of courses targeting both executives and Scrum practitioners and has recently launched a new website which incorporates a similar big picture concept to that proposed by SaFe [16].

DaD (Disciplined Agile Delivery) [17] is proposed by Scott Ambler, and is an evolution of his work on the EUP (Enterprise Unified Process) [18] which in turn extends the RUP (Rational Unified Process), [19]. DaD proposes a hybrid approach to scaling Agile and incorporates strategies drawn from a range of lightweight methods and Lean principles as well as mandating a set of prerequisite core practices. DaD claims to extend Agile principles across the system lifecycle and provides approaches to managing challenges such as geographically diversified delivery teams, complex organisational structures and multiple technology platforms [20].

SAFe is the most recent of the Agile in-the-large frameworks and is based on the work of Dean Leffingwell [21]. SAFe proposes a three-tiered approach to scaling Agile, which address the needs of the team, the program and the portfolio. SAFe is the first Agile in-the-large framework to offer a complete package of supporting software, certification schemes, books and training courses driven by an intensive marketing effort [22]. SAFe claims to provide a proven approach to scaling Agile, a claim supported by a number of customer case studies. Software vendors have developed tools designed to support SAFe through both their product and through training and certification.

SAFe has been the topic of some particularly heated discussions found in the technical literature. These highlight strong concerns voiced by many well-respected authors, practitioners and thought leaders. Who, whilst acknowledging that one of the strengths of SAFe is its basis in Lean principles have raised concerns about whether the framework actually supports the principles and values which underpin Agile, or whether it undermines them [23]. A focus on standardisation, large scale planning and taking a top-down approach are also highlighted as potential problems, primarily due to an apparent focus on process rather than on people [24]. SAFe claims to present approach to scaling Scrum, yet Ken Schwaber one of the designers of Scrum argues that SAFe is based on RUP rather than Scrum [25]. Ron Jeffries one of the original designers of XP also highlights the centralised approach to planning dictated by SAFe as an issue [26].

Both DaD and SAFe add new rituals, practices and other modifications to existing Agile methods, both propose significant organisational change and both claim to address corporate governance issues; DaD through blending traditional and Agile thinking and SAFe though offering transformational patterns as a bridge from traditional to Lean-Agile approaches. All the frameworks discussed in this post are associated with large amounts of expensive supporting material, such as, training courses, certification schemes, supporting software products and of course highlight the need for specialist consulting as a pathway to success.

These frameworks are primarily designed to assuage the concerns of organisational governance teams who are keen to leverage the perceived benefits of Lean and Agile approaches, whilst mitigating a myriad of well-documented inherent risks. Whilst all these frameworks emphasise adaption to meet the needs of implementing organisations, they are presented as highly prescriptive pathways to success and unlike Agile implementations at the team level there is very little empirical evidence in the substantive literature to support claims that these approaches are proven or that they represent a good investment of potentially very large amounts of money. More conceptual approaches such as Lean governance and those associated with Agile in-the-small, (meaning the use of specific practices such as XP, pair programming, BDD and TDD) are well researched and there exists a great deal of empirical evidence to support the idea that in various circumstances, these practices can deliver benefits; but on their own they are not sufficient.

The way forward

So what is the way forward? How can organisations take advantage of Agility to help them respond to new and rapidly evolving demands and opportunities, whilst continuing to minimise risk, and meet their obligations to stakeholders? The research on organisations which have implemented Agile-in the large still presents us with more questions than answers [27] ; however we can identify some of the organisational characteristics which seem to influence perceptions of success.

Key amongst these is the need for a shared understanding of what Agility actually means along with clarity of purpose from an organisational governance perspective [7]. For example if your goals are around increasing speed to market or making improvements to product quality within an existing culture and governance framework, then a structured approach or framework will probably be appealing. Especially if that framework also suggests that you can do these thing more efficiently (cheaply) by adopting it. But this is not Agility; this is procedural change and much of the existing research suggests that organisations that confuse Agility and process improvement will not be satisfied with the outcomes nor will they achieve the certainty they desire. If, on the other hand, your goal is to deliver value to your customer through understanding and responding to their needs you are not only starting from a different place but will need to take a very different approach. Structuring your organisation around this goal can require a seismic shift to an organisations culture and management style. Wanting to be better able to respond to an uncertain and disrupted marketplace demands a level of tolerance for uncertainty that many organisations struggle with.

In addition to a shared vision and clarity of purpose, the characteristics shared by organisations that perceive themselves to have been successful in this regard are:

An understanding that the biggest challenges are likely to be around people, perceptions and concepts rather than technical [5]
A willingness to iteratively experiment and to learn
A culture that engages and empowers both employees and customers to be part of the experiment and learn cycle
Transparency in everything, including things which don’t work
Patience; being willing to start small, measure and build on small improvements in customer value, and employee satisfaction

Conclusion

Enterprise level Agile is not well researched or understood and whilst many of the challenges associated with scaling Agile have been identified, approaches to solving them are emergent and potentially immature. Whilst frameworks such as DaD and SAFe which propose step-by-step approaches to implementation may seem appealing and present attractive testimonials and case studies to support their claims, these claims are not based on empirical research and in many cases are at odds with the empirical evidence which is available.

References

[1] K. Conboy, “Agility from First Principles: Reconstructing the Concept of Agility in Information Systems Development,” Inf. Syst. Res., vol. 20, no. 3, pp. 329–354,478, 2009.

[2] K. J. Riemer B., “Digital Disruption,” Backed By Research, 2014. [Online]. Available: https://byresearch.wordpress.com/2013/03/07/digital-disruption/.

[3] S. Girn, “Digital Disruption – Opportunities for Innovation and Growth.” Reserve Bank of Australia, 2014.

[4] P. Adamczyk and M. Hafiz, “The Tower of Babel did not fail,” ACM SIGPLAN Notices, vol. 45, no. 10. ACM, Reno/Tahoe, Nevada, USA, p. 947, 2010.

[5] B. Boehm and R. Turner, “Management challenges to implementing agile processes in traditional development organizations,” Software, IEEE, vol. 22, no. 5, pp. 30–39, 2005.

[6] S. C. Misra, U. Kumar, V. Kumar, and G. Grant, “The Organizational Changes Required and the Challenges Involved in Adopting Agile Methodologies in Traditional Software Development Organizations,” in Digital Information Management, 2006 1st International Conference on, 2007, pp. 25–28.

[7] A. Mahanti, “Challenges in Enterprise Adoption of Agile Methods -- A Survey,” J. Comput. Inf. Technol., vol. 14, no. 3, pp. 197–206, 2006.

[8] G. Van Waardenburg and H. Van Vliet, “When agile meets the enterprise,” Inf. Softw. Technol., vol. 55, no. 12, pp. 2154–2171, 2013.

[9] C. Rand and B. Eckfeldt, “Aligning strategic planning with agile development: Extending agile thinking to business improvement,” in Proceedings of the Agile Development Conference, ADC 2004, 2004, pp. 78–82.

[10] K. Logue and K. McDaid, “Agile Release Planning: Dealing with Uncertainty in Development Time and Business Value,” in Engineering of Computer Based Systems, 2008. ECBS 2008. 15th Annual IEEE International Conference and Workshop on the, 2008, pp. 437–442.

[11] V. Heikkilä, K. Rautiainen, and S. Jansen, “A revelatory case study on scaling agile release planning,” in Proceedings - 36th EUROMICRO Conference on Software Engineering and Advanced Applications, SEAA 2010, 2010, pp. 289–296.

[12] K. Power, “The Agile Office: Experience Report from Cisco’s Unified Communications Business Unit,” in Agile Conference (AGILE), 2011, 2011, pp. 201–208.

[13] P. Saddington, “Scaling agile product ownership through team alignment and optimization: A story of epic proportions,” in Proceedings - 2012 Agile Conference, Agile 2012, 2012, pp. 123–130.

[14] J. Pernstål, R. Feldt, and T. Gorschek, “The lean gap: A review of lean approaches to large-scale software systems development,” J. Syst. Softw., vol. 86, no. 11, pp. 2797–2821, 2013.

[15] S. Ambler, “Disciplined Agile Delivery,” 2014. [Online]. Available: http://disciplinedagiledelivery.com/.

[16] “Large Scale Scrum (LeSS),” 2014. [Online]. Available: http://less.works/less.

[17] “Scaled Agile Framework,” 2014. [Online]. Available: http://scaledagileframework.com/.

[18] S. Ambler, “Enterprise Unified Process (EUP): Strategies for Enterprise Agile,” 2014. [Online]. Available: http://enterpriseunifiedprocess.com/.

[19] “IBM Rational Unified Process (RUP),” 2014. [Online]. Available: http://www-01.ibm.com/software/rational/rup/.

[20] A. W. Brown, S. Ambler, and W. Royce, “Agility at scale: economic governance, measured improvement, and disciplined delivery,” in Proceedings of the 2013 International Conference on Software Engineering, 2013, pp. 873–881.

[21] D. Leffingwell, “Dean Leffingwell,” 2014. [Online]. Available: http://deanleffingwell.com/.

[22] P. Saddington, “The Scaled Agile Framework (SAFe) - A Review | Agile ScoutAgile Scout,” 2014. [Online]. Available: http://agilescout.com/scaled-agile-framework-safe-review/.

[23] N. Killick, “The Horror Of The Scaled Agile Framework | neilkillick.com,” 2012. [Online]. Available: http://neilkillick.com/2012/03/21/the-horror-of-the-scaled-agile-framework/.

[24] A. Elssamadisy, “Has SAFe Cracked the Large Agile Adoption Nut?,” InfoQ, 2014. [Online]. Available: http://www.infoq.com/news/2013/08/safe#.

[25] K. Schwaber, “unSAFe at any speed,” Telling it Lite it is, 2014. [Online]. Available: http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/.

[26] R. Jeffries, “SAFe â€“ Good But Not Good Enough | xProgramming.com,” 2014. [Online]. Available: http://xprogramming.com/articles/safe-good-but-not-good-enough/.

[27] D. Torgeir, B. M. Nils, T. Dingsoyr, N. B. Moe, T. Dingsøyr, and N. B. Moe, “Research challenges in large-scale agile software development,” SIGSOFT Softw. Eng. Notes, vol. 38, no. 5, pp. 38–39, 2013.

As an agile business analyst, I want...

2015-07-26T10:46:00.001+10:00

Don't be a story monkey

The words and pictures we use to describe things...

2015-06-24T07:50:00.000+10:00

... conceal as much as they show.

An insighr from this very interesting article.

An investigation into Self Organisation

2015-05-30T08:25:00.001+10:00

We ran a meetup session with the local Scrum User Group discussing Holocracy, a model for self-organizing teams. After the discussion about Holocracy led by Julian Waters-Lynch, we then ran an activity exploring our own appetite for self-organisation.

I’ll share what came out of the discussion in two future posts;

How self-organised do we think we are, and what’s holding us back
How self-organised do we want to be, and what will signal success.

I asked the room to take two different coloured index cards (green and yellow if you must know) and the gave people two jobs.

On the yellow cards I asked people to rate their current organisation's level of self organisation from 1 (low) to 10 (high.) I then asked them to write down some points on what holds them back.

Then, on the green cards, I asked people to rate their aspiration for self organisation (same scale) and to write down what they would see as signals of success.

I have plotted the scores in the chart below.

This is from a group of people who are curious and motivated enough to come out to a work themed event at 6pm on a weeknight, so they are at least somewhat engaged at work.

I personally can't read much from the chart alone except that there is a wide spread of answers to the question and that most people's aspirations live around the 7-8 out of 10 mark. Perhaps this is a natural conservatism, or simply a focus on next stages of growth.

So in the next few days I will post more, showing what comments people said in the context of what scores they were giving.

BA Effectiveness survey

2015-05-22T07:44:00.002+10:00

I am running an NPS like survey on Business Analysts. I'd appreciate your sharing this out to your professional network. What do people think about Business Analysts?

So far I have close to 100 responses and there is a pretty positive set of feedback. The comments are interesting as well.

I want more though and I need your help. Share this out for me.

http://bit.ly/1JRnYGc

I'll publish the results here in August.