Our future is an increasingly uncertain place, with consumer expectations and technology rapidly changing. The geospatial industry needs to be more adaptive, collaborative and creative if we want to ride the waves of disruption and deliver on our potential for growth.
Although national coordination is needed, we don't need to wait for it. We can all play our part in growing and developing the industry and the role geospatial plays in each of our domains.
This presentation presents a starter recipe for creating and empowering self organising geospatial teams in an agile and nimble way to improve the way we work and lead us to deliver more innovative geospatial products and services.
19. DO WE NEED THIS RECIPE?
47%use sprints
46%use git
“This
shit
works” “Agile as currently executed by most
projects is an abomination”
“biggest problem we face
is the willingness of
clients to understand the
benefits of agile
development”
“What is
agile?”
15%
“Parts of the org use
Agile techniques but
not the geospatial
section.”
use design thinking
20.
21. • 6-7 people on a team
• Everyone can make
decisions
• Safe environment
• Learning and growth
mindsets
INGREDIENTS
• 1/4ly goal setting
• 2-3 Weekly sprint planning
• Daily standups
• End of sprint retrospectives
• Hacktime
• Showcases
METHOD EQUIPMENT
• Github/bitbucket
• Wiki/confluence
• Trello/jira/taiga
Editor's Notes
Before I dive into sharing my recipe – i wanted to touch on why it is important to work in a self organising way.
Kent beck – the author of extreme programming highlighted this in 2000
“The business changes.
The technology changes.
The team changes.
The team members change.
The problem isn't change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes
But even in 500 B.C.E Heraclitus spoke the famous words “Nothing endures but change”
Change has always been around
Yet some of us are still working ways that are not as conducive to adapting to change.
The problem NOW is that change is accelerating.
You may have all heard of Moore’s law - the number of transistors on a circuit is doubling every 2 years.
But Moore’s law is actually the 5th paradigm of our growth in technology. Ray Kurzweil’s (who is Google’s futurist amongst many other things) proposed a law of accelerating returns back in 1999 which shows we are facing a wall of exponential growth in terms of technological progress and the profound social and cultural change that will come with that. In fact, his law says that in a couple of decades machine intelligence will surpass all of human intelligence combined. It’s a little bit scary, exciting and hard to believe.
But we can’t ignore it. We need to set ourselves up to adapt.
Have a listen to Kaila Colbin’s talk on exponential organisations.– we must get better at working in a way that can adapt to change.
http://www.singularityunz.com/modules/speakers/kaila-colbin
At iag – Australia and New Zealand’s largest general insurer – my place of work – where we have a team of 12 location engineers – formally geospatial analysts – iag has recognised that as a company we need to work in a way that will help us adapt to this change.
More recently – we’ve introduced agility as a key drivers to help us adapt to change and deliver more for our customers.
We’ve defined it as …..
Delivering major pieces of work in smaller chunks with quicker implementation; better understanding the needs of the future workforce and workplace so we can equip our people today to meet the working needs of tomorrow.
And we’ve recognised that working in an agile way is not just for teams in software development.
This has led us to rethink how we structure our organisation, our teams and ultimately the way we work.
We’ve moved from a mindset of individual contributors in a hierarchy of single point decision making
To teams or “squads” who collaborate, plan together, and are self organising. Not locked into our special geospatial corner, but working and collaborating in project teams with other disciplines and with eachother.
To teams who can decide what we work on together and can quickly plan and adjust to change.
Over the last year I have led our geospatial team through the transformation from individual contributors and single point decision making to our collaborative and self organising team.
We’ve learnt a few things that we can share.
One of the first things we learnt and I would like you to take away - was to rid ourselves of the mindset “But geo is special – we’re not developers, we have unique work that needs its own way of working, our own tools, our own practices.”
We are developers!!!!! We are data engineers! We are designers!
We need to be focused on building the knowledge and skills to automate our tasks, or use frameworks like design thinking to design amazing, innovative geospatial products, to create and to collaborate with our customers and with each other.
https://www.interaction-design.org/literature/article/5-stages-in-the-design-thinking-process
We need to be leveraging the practices and frameworks that the development and design industries are using.
Working in an agile, and self organising way will help get us on track.
But the track can be complicated when you are first starting out. There are a few iterations of the agile landscape.
I'm not here to give you a course on agile project management and the frameworks you could use.
But what I can give you is a starting point and a recipe that we’re currently using to help us evolve into a self organising team.
Agile at its very core is a mindset – about delivering faster, in an iterative way, adapting to change in a collaborative and self organising way.
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
Working in sprints, or shorter iterations to deliver a minimum viable product and then iterate on that. Adapting, and pivoting as needed but working collaboratively throughout the process.
What i will share - are some of the ingredients, methods and tools to help fast track your transformation into a self organising team. Whether it is a project team or a functional team.
This is a flexible recipe.
If you want to remove the sugar –go ahead
Swap out the milk for something else – go ahead
I will give you the ingredients to get started but ultimately each team is different so I would encourage you to adapt the recipe to suit your needs.
Jeff Bezos, the founder and CEO of Amazon introduced the idea about 2 pizza teams – a team should be no larger than what 2 pizza’s could feed – so 6-7 people. Other studies put a maximum at 10. But any larger then that and communication starts to break down and self organisation becomes difficult.
Everyone must be empowered to make decisions. The team knows best, give them the autonomy to call the shots and make decisions. The team should have ownership and responsibility for what they produce.
Google did 4 years of research on what are the most important factors to successful teams and psychological safety came out as number one. This is crucial to the success of a self organising team. The team must be able to call eachother out, keep eachother accountable and to feel safe to take risks and be vulnerable in front of eachother.
Learning and growth mindsets - I believe we need to get a lot better at educating ourselves and growing ourselves in our teams to be able to work with new tools, new technologies new ideas because they're coming at us faster. And doing it in a collaborative way, pair programme, have time set aside to dedicate to learning new technologies as a team. Help eachother upskill.
https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/
We all do this, whether we’re a sales team in a geo consulting company, a geospatial team in an engineering firm or a team of location engineers at an insurance company. We need to set the direction for the team.
But where we previously did it once a year, we now come together to refresh and remind our vision and develop our strategic goals quarterly. This helps to keep us on track, aligned and the ability to review and repoint our strategic direction, if the business change, market changes or our customers need changes.
We need to be working in smaller chunks. Which allows us to deliver faster and adapt to change. We might work in a sprint of 2 weeks, where we come together and work out what we are going to deliver in that 2 week period. We clarify the requirements together, prioritise them together, agree to the tasks required to deliver them together.
And we track and communicate daily in short, sharp standup. What did you do yesterday, what are you planning on doing today? Are there any blockers we can help fix?
Finally, i think most importantly we have time to focus on continuously improving the way that we work as a team. What went well this past iteration, what didn't, what should we start, stop, or continue doing. And making sure as a team you pick things to focus on.
1/4ly goal setting:
Refresh/revisit vision
Develop/refresh strategic objectives – OKR’s (objectives and key results)
Communication plan
If it’s a long term project team – we will revisit the strategic objectives of the project.
Sprint planning:
We get together as a team for an hour to
Confirm what was delivered last period
Review availability and resourcing
Agree on priorities for the two weeks
Agree on what we want to deliver within the two weeks. For example, we might say this sprint we will build a plan to roll out desktop mapping software to the business. We will test the plan with 5 known users. Or this sprint, we will deliver a mvp of a cyclone impact map with policies affected, and live claims.
Clarify any tasks
Daily standups
A quick short meeting, 15 minutes at the beginning of each day, where we literally stand up and each person talks about what they did yesterday, what they are planning on doing today and calls out any blockers or help they may need. The team can keep eachother accountable to our sprint plan and we can keep things moving by resolving blockers quickly. We tested the roll out of desktop mapping yesterday and today i will update the plan with our learnings. Or yesterday i created a script to automate the feed of claims data. Today im going to...
Throughout the sprint we may also run showcases or deep dives as needed. This can be 5-10 minute short presentations to the team on a particular project, technology to share knowledge. OR sometimes we use it to crowd source ideas for a project.
We also have time throughout the week dedicated to hacking. A time pressured environment to produce a product or a hack with new technologies, or ideas. That is safe place to fail and take risks.
Retrospectives:
Issues to focus on to continuously improve as a team
What should we start, stop, continue doing
Finally, as with any recipe, the use of some standard tools will help in creating a self organising team.
Again – if you are creating geospatial data, creating web maps, are you doing it a way that is automated? That code would be stored in git. Tools like github or bitbucket will let you share, update and collaborate on code together while maintaining version control.
Collaborative document control –when you document you democratise knowledge. You remove single point sensitivities. This will become more and important as we move to more remote teams.
You might be using githubs wiki, or confluence
Fianlly - Collaborative task management – it might be something as simple as wall of post it notes with a to do, doing, done column. Or if you are running a few different projects in the team – tools like trello, jira or Taiga help enable the self organising as work is made transparent
Do we need this recipe? As an industry are we already working in an agile and adaptive way? I wanted to validate my feeling that we are not utilising the frameworks that the development and design industries are using. And perhaps not working in a way that is as adaptive to change as we could be.
I put out a survey a couple of months ago and publicised it on twitter, on linked in, through word of mouth.
I received 37 responses – and thank you to anyone who responded!
Ill share some quick results, but I'm planning on keeping this open longer so I can do a more comprehensive write up on the results when i get more respondents.
So of the 37 people who responded – 43% don't use agile. And 32% are fairly new to adopt agile.
Our teams are changing – from being co-located on site – where communication is over the desk to remote and flexible teams over virtual meetings and video conferencing, where communication becomes more of a challenge. Having a framework or a recipe will help put the structure in place to self organise in the virtual workspace.
72% of the geospatial teams that responded to my survey are already working in a remote, flexible or hybrid team.
A framework for designers to create innovative and desirable products.
-The hype of agile – lack of planning and thought being labelled as agile
Just to leave you - This is from one of my favourite blogs – wait but why on a post about AI. The author Tim Urban introduces the topic using the law of accelerating returns and I think he puts it really well – when he points out we’re very good at thinking linearly and although this is what it feels like at the moment
But the far future is coming very soon, so what recipe will you use to help you adapt?