Today's accountability focuses on my continued fitness goal, this time breaking down an initiative many people in my organisation have decided to undertake.
GCC provides employers with a simple and engaging way to create a true culture of health right across the business.
For a period of 100 days starting on 27 May 2015*, hundreds of thousands of employees around the world will compete in teams of seven as the GCC takes them on a journey that will increase their physical activity levels and improve their diet and the quality of their sleep.
https://www.gettheworldmoving.com/program-overview
The Global Corporate Challenge asks competitors to wear a pedometer every day and then directly enter their steps in to the online profile. Grouped into teams their progress takes them across a world map with the goal of 'walking the whole world' in your team.
There are some problems with the programme. The app is barely functional, the pedometers are clunky ugly chunks of plastic that don't have a set sensitivity level, and potentially the most dubious thing about the programme is that individuals have to enter their own steps into their profile every day. Not that I don't trust my team mates, but without a firm way of tracing steps with a secure method of uploading the step data without it being tampered with, the entire process needs to be viewed as slightly suspect.
Meh.
Thankfully the GCC has a FitBit integration so I needn't have to rely on the GCC pedometers. Logging into the GCC profile I have to confirm the steps I've done so far and then it updates my progress. I can compare my average to that of my team mates, many of whom also own FitBits but also it gives a greater accountability to my fitness and steps taken.
Overall I find the GCC a great concept with a somewhat flawed execution. We are currently in the early stages of the challenge with more yet to discover. So far I feel slightly motivated to beat the average daily step count from the 2014 challenge; 13,618, but I feel the greater motivation will continue to come from personal competitions set up through the FitBit.
Today's accountability blog focuses on writing my CV, which means that today's post may be even more naval gazing than usual.
I've never been good at self promotion, which is why in part this task in my personal development agile journey is so important. Writing a good CV is incredibly important to not only keep abreast of my current skills if I ever decide to change jobs or companies but it is also a positive task to ensure that I'm aware of what I've accomplished. With this in mind I plan to update my CV around twice a year.
When writing the CV I broke it down into several parts:
Personal statement
Work experience
Qualifications/Certifications
Interests
In keeping with the spirit of agile I broke each of the sections down and focused on deliverables for each. Instead of stating and listing the tasks I've undertaken I've shown what I've actually produced/delivered and stated why that brought value.
This approach hopefully shows my worth, what I've achieved to my current employer whilst also showing those potentially interested in my services that I can deliver complete projects and the value I can provide.
Previously we reviewed the Agile Manifesto, the constitution of agile development, and in today's post I present to you the more direct follow up to clarify a few things. The Bill of Rights of agile development; the Twelve Principles.
The Twelve Principles of Agile Software
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Looking at these principles it is clear to see a few themes emerging and being expanded upon from the initial manifesto.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Delivering results that are actually wanted by stakeholders and maintaining a frequent flow of progress. Isn't that an awesome goal for people to strive to achieve?
Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
Things change, don't bitch about it. If you were hosting a dinner party, planned a hog roast and then find out all your guests are vegans. You could grumble, but people are coming across, why not dive into learning new vegan recipes? Rise to the challenge.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Show actual progress over time, it's more exciting to show gradual improvements in chunks than deliver a massive project that is no longer relevant.
Business people and developers must work together daily throughout the project.
Be interconnected within a team, it helps focus on the project, in a personal development setting this is incredibly important to retain accountability.
Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.
Get team buy-in and support in a project, it helps if they're passionate about it. In a personal development setting this would suggest that you focus on something you truly see as a worthy goal. If I wasn't bothered about fitness and all I wanted to do was to read, knowing fitness is important, I would begrudgingly put it into sprints, but it would be far more difficult to reach the goals.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Be clear and honest in communication, so many times people infer so much from text when there's really nothing there.
Working software is the primary measure of progress.
Deliverables = progress.
Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
'It's better to burn out than fade away' - Nope. Why not continue on the path delivering constantly. The Government Digital Service said that 'Boring is beautiful' - that's not a bad thing.
Continuous attention to technical excellence and good design enhances agility.
Be mindful of following the best practices. Find and follow best practices, they're best practices for a reason.
Simplicity--the art of maximizing the amount of work not done--is essential.
Why over complicate things? Keeping it simple ensures you can do it again, repeating tasks. It's easier to explain to others and it helps others understand what you're doing.
The best architectures, requirements, and designs emerge from self-organizing teams.
Teamwork is good and best practices emerge from sharing resources with those you trust.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
If you perform a task in the exact same way why would you anticipate a different reaction? Play around and find what works, find your groove and work into it. You improve your approach through revising it.
These principles work with self improvement and when reduced to their essence can work in many things in life.
You have to
Stop
Review what you do constantly, don't get carried away
Collaborate
Work within teams to achieve everything you need to, sharing resources and responsibilities
Listen
Work with your stakeholders, don't bury your head in the sand
With the principles and manifesto broken down it is clear that agile can be utilised in all strands of life, professional and personal.
In today's post I thought it best to go back to the original manifesto that agile came from.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
http://agilemanifesto.org/
There it is in all its dandy glory, but where did it come from and what does it represent?
The Agile Manifesto was written in February of 2001, at a summit of seventeen independent-minded practitioners of several programming methodologies. The participants didn't agree about much, but they found consensus around four main values.
Supplementing the Manifesto, the Twelve Principles further explicate what it is to be Agile.
http://www.agilealliance.org/the-alliance/the-agile-manifesto/
So, the agile manifesto is like the US constitution and the Twelve Principles is similar to the Bill of Rights. Let's examine the manifesto and then see how these principles can be applied to personal development. The manifesto focuses on valued areas and promotes some concepts over others.
Individuals and interactions over processes and tools
This states that the human element is more important than the machine they are a part of. Yes we are awesome little snowflakes, completely original, but we work so much better and have much greater impact combined together as a snowball; and there are many ways to make a snowball. Working software over comprehensive documentation
If it works and we know conclusively how it works with extensive documentation of how it does the thing we want it to, awesome. That's great, but what's the most valuable part of that? The actual thing that works, this is what should be prioritised. We should constantly be asking ourselves, does it work? Customer collaboration over contract negotiation
Contracts are incredibly important and help define terms, but when you strip the contract down what is actually required? As an individual/team/company, you have been asked by somebody else to create something. Collaborating and building to a fluid specification is important as it keeps everyone in the loop and allows all parties to be open and honest with each other. The client is happy because you build what they want, and you're happy as your customer isn't going to completely flip out at the end of the project because you haven't delivered what they (didn't) ask for.
Responding to change over following a plan
Sometimes teams continue down the road outlined down at the start of a project even if they're no longer aware if it's possible or not. Can we just take a second to put this into context in the real world. You're driving down the motorway, the sat-nav says to go left over the bridge, you see a new sign stating the bridge is being repaired and to cross it would be certain death. Do you listen to the sat-nav you decided to listen to at the start of your journey or the new sign directly infront of you? It's surprising how often a company will drive off a cliff...
That is, while there is value in the items on the right, we value the items on the left more.
So, we can see value in plans, contracts, processes and documentation, but when we start a project, we need to drill down and look at the core of what is being said. So how can we repurpose our own personal development agile manifesto?
Wellbeing and conversations over goals and tasks Results over comprehensive planning Teamwork and maintaining the essence of the vision over initial epics
Responding to surroundings and embracing opportunities over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
I'm happy with the above changes and find them relevant whilst keeping in the spirit of the original manifesto.
Today's accountability blog is about the podcast task I've been assigned this sprint:
'This sprint I plan on continuing to listen to Entrepreneur on Fire and Entreleadership podcasts, adding in Quick and Dirty Tips'
Whilst Entreleadership and Entrepreneur on Fire are around 40 minutes in length and follow an interview format, Quick and Dirty Tips podcasts are around 10 minutes and focus on one topic. In this sprint I've been listening to the following 3 podcasts:
The Get it Done Guy
Narrated in a quirky style using geek and pop culture references to illustrate various situations. The advice is sound and the tips provided do have value, however sometimes the zany voices are just a bit too much. That said, the tips are valuable and the insight is worth the grating presentation sometimes. Kudos to the constant Little Shop of Horrors references though.
The Public Speaker
This podcast explains simple approaches to public speaking from mindset to actual physical exercises to improve public speaking. The practical examples and real life critique of events such as a breakdown of acceptance speeches at award ceremonies make this podcast accessible and relevant. I can see myself revisiting the back catalog of this series to help improve my speaking skills.
The Nutrition Diva
In a different approach to the other podcasts, The Nutrition Diva reviews recent research journals and periodicals to cut through the hype with science. Always promoting positive nutrition, a healthy diet and frequent moderate exercise, the podcast is a grounding influence that gives actionable tips whilst raging against faddy diets.
I have listened to all three before at various times, however in a new sprint environment I can listen to all 3 in less than 30 minutes on a weekly basis, a positive habit to develop.
I can recommend all three and may integrate other QTD podcasts in future sprints.
You join me in my first accountability session in my second sprint. In this sprint I decided that I would read 'Ready Player One' by Ernest Cline. Although the book was only published in 2011 it has had a large impact on geek and nerd culture at large.
Set in a dystopian future not too far from our own, the world faces a terrible energy, food and population crisis with much of the world plugged into the virtual reality simulation game called 'the Oasis'. In this game players plug into virtual reality through a headset and haptic gloves and can interact with other players as well as non-playable characters.
When one of the creators of the Oasis dies a chase begins to find the secret to his will likely his fortune within the Oasis. This leads to a competition in the vein of 'Charlie and the Chocolate Factory' crossed with 'The Hunger Games' drenched in a glut of 1980s nostalgia.
Having listened to the book across a couple of days I really enjoyed it however I do feel that it has an awkward target to hit, the book is aimed at the young adult market however some of the references linked to the 1980s may not strike a chord with the intended audience, but Cline describes everything with vigour and enthusiasm without having to labour it. The references come thick and fast some more heavy handed than others, I particularly enjoyed a couple of very apt 'Brazil' references, however not all of them have the same impact.
Would have I enjoyed it more if it focussed more on the 1990s games I grew up with? Most likely, I would've punched the air in joy if there were Jazz Jackrabbit and Sonic the Hedgehog references, but then again this is a book which sets itself firmly in a dystopian time, harkening back to a very specific period; the 1980s.
I enjoyed the book, the narrative I found familiar, but is that such a bad thing? I felt this was aiming to be a postmodern dystopian nightmare in places, which it was, however the postmodern flavour was less Coupland eccentricity of accepting the modern bleakness and more George Lucas, holding out for a hero that can still save the world.
I think the story does work, it paints gaming in a realistic light showing why people feel compelled to plug themselves in to another life, there are some stereotypes, but is that a bad thing? Whilst the story heavily references the 1980s and pop culture touchstones, the text and story itself is highly reminiscent of classic young adult films from 'The Goonies' to the John Hughes catalogue.
Can it teach me anything about agile? Maybe, the gamification of the quest sets the book nicely into sections, it also shows how an impossible goal can be completed in small chunks, similar to agile.
I'll be really intrigued to see the movie adaptation and if they can evoke the same feeling, Spielberg is currently signed to direct; and it makes sense as he's likely the only person in Hollywood who has enough good will to get the license to Star Wars, Back to the Future, Blade Runner and the Atari back catalogue.
This post is a special one in that it links Thinking Digital (#tdc15) with the actual topic for this blog, agile!
Whilst there were speakers at the event who brushed on agile and scrum methods, the head of the Government Digital Service held a joint presentation on how they've updated the entire government digital system to be a fully accessible interactive platform.
Russell Davies (@undermanager) is a self proclaimed GDS Jedi with a background in advertising agencies working for clients such as Nike, Apple and Honda, including that Honda advert.
He is currently Director of Strategy at the Government Digital Service - working out how a Digital Government integrates its products, services and marketing - thinking beyond government as a website and figuring out how we deliver Government As A Platform.
Davies starts with a simple statement, 'The strategy is delivery'. The product required was a platform for the Government Digital Service and with Gov.uk they built a platform for publishing that has over 12 million users every week. The platform built to confirm identity has 19,000 authentications per week alone.
As the civil service is under constant scrutiny the team must prove the value of the new digital services. Davies believes the team is already achieving this. With the creation of the digital marketplace of skills government vendors can be sourced more efficiently from local sources. Removing the London-centric bias of the civil service will take many years but by moving services to a neutral online location goes a long way to help this. The implementation of the new digital platform may cause some stress but it will save billions.
Now that they've justified the case to build to stakeholders the team have embraced an agile concept. ‘No innovation until everything works’. The Gov.uk website is boring, by choice. The team would rather have a fully functioning product that can achieve all basic functions required by the users is far more desirable than an impressive but heavily niched site. The Gov.uk team ensures full functionality of a feature before moving on to something else, essentially the function must be signed off as 'done done' by all stakeholders, something critical for a government website.
Ensuring that the new functions are supported is incredibly important, Davies brings up how many cash machines are having to have costly patches added to them as they cannot upgrade past the no-longer supported Windows XP. This is not acceptable for a state website and as a result they have developed core principles to ensure this kind of situation never befalls them.
In keeping with these principles the Government Digital Service has made the surprising choice to actually make all their code open source on GitHub, perfect if you decide you need to start your own country and require a complete digital service solution...
This openness is important in agile, becoming transparent and quick to act allows quick change and more honesty, something that can only improve perceptions of not only governments but business too.
The team behind Gov.uk strain to have user centric design, and whilst it may appear boring, boring is fantastic. Boring works, boring is simple and boring allows users to understand a system fully.
Ade Adewunmi works alongside Davies and is the driving force to push Government as a Platform. Adewunmi is central to GDS’s emergent strategy approach: that only by prototyping is it possible to create digital products and services in a way that matches the realities of delivery. And that just like digital services, strategies need to be iterated. She believes that the best way to get results is Revolution, not evolution.
Before we start worrying about revolutionaries in the heart of the digital government wanting to start a new world order, Ade refers to revolution in the way she aims to push new processes. Revolution describes the rapid culture change needed, rather than slowly move a tanker around to reach a destination, blow it up and use a nippy speedboat to get there!
That's not to say evolution has no place, as obviously agile as a method relies on the constant revision and improvement of a core, the evolutionary process helps test features and refine the culture however upheaval may be required to ensure buy in.
The Gov.uk team has:
Delivered a lot
Learned a lot
Changed a lot
By focusing on the user journey the team has built a new system, it was rigid where it had to be and flexible where it allowed. The user's journey, from end to end was reviewed constantly by researchers who helped inform the development team what worked and what would not. By opening the system and ensuring open standards, the team had flexibility with an added consistency across each project. This was critical for a large scale, multi stakeholder service development.
This links on to the roadmap, by being completely open in practices with stakeholders the team has delivered everything required and everyone is aware of how. Stakeholders and usability are core to this, with the teams not allowed to move on to mobile apps or cool interesting features until the core system works fully.
Under Adewunmi there have been core open standards which have worked when:
They are made clear and responsive
Support us provided and the standards enforced
How does Adewunmi see the future? Government as a platform
The Government Digital Service will strive to ensure everything they build is a service or platform, not just a website.
As a parting piece of guidance Ade tells us to ask ourselves some questions whenever we build something;
What are you building?
Why?
How can it be improved?
The story of the GDS is inspiring and shows what can be done with agile, whilst also offering practical advice to ensure you get the most from your agile projects. A fantastic talk by two great speakers, and an excellent session at Thinking Digital.
Let's move on to the second sprint. Pulling the stories, tasks and acceptance criteria for what I hope to achieve! Onwards!
Let's look at the brand new board, that isn't actually that new but more an iterative continuation of my progress so far, GO AGILE!
Let's begin with the business/career/studies segment:
Stories
Tasks
As an agile Timelord I want to read one non-fiction book a month so that I become more knowledgeable on useful and interesting topics.
This two week sprint I plan to read 'Happiness by Design'
As an agile Timelord I want to read one fiction book a month so that I become more well-read and cultured.
This sprint I plan to read 'Ready Player One'
As an agile Timelord I want to listen to 4 business podcasts a week so that I learn more about business culture and best practices.
This sprint I plan on continuing to listen to Entrepreneur on Fire and Entreleadership podcasts, adding in Quick and Dirty Tips
As an agile Timelord I want to rewrite my CV so that I keep abreast of my skillset and can compare myself to other professionals in the marketplace
Rewrite my CV so it is fully up to date
As an agile Timelord I want to learn how to code so that I can understand a selection of coding languages and processes
Use Khan Academy or Codecademy to learn basic coding
Spiritual:
Stories
Tasks
As an agile Timelord I want to feel calm and confident through meditation so that I am less stressed
I will download the Headspace meditation app and work through the 10 day programme
The task is marked in blue as I have started it but not completed it to my own satisfaction.
Health:
Stories
Tasks
As an agile Timelord I want to work out at least 5 times a week so that I lose weight and tone my body.
I will use a fitness DVD in the mornings, waking up an hour earlier to do so
As an agile Timelord I want to walk at least 10,000 steps each day so I set myself an active benchmark to lose weight.
I will track my steps using a Fitbit Charge HR tracking my progress using the app and dashboard. As such I will aim to have a weekly accumulative total of 70,000 steps
As an agile Timelord I want to chart my progress and set a target of losing 2lb of weight a week so that I can reach my overall goal.
My current weight is 199lb, by weighing myself daily and keeping up with my more active lifestyle I will track my progress
Personal Growth:
Stories
Tasks
As an agile Timelord I want to be able to feel confident in any situation so that I am comfortable
I will attend the local Toastmasters meeting to build up my confidence in public situations and learn greater public speaking habits
As an agile Timelord I want to write a personal speech so that I'm prepared for giving speeches in the future
Write first draft of speech
As an agile Timelord I want to learn best practices of speakers so that I am a competent speaker myself
Watch 5 TED talks
Social/Community:
Stories
Tasks
As an agile Timelord I want a growing blog so that I grow my writing skills
I will update the blog daily informing of my progress, experiences and future plans.
As an agile Timelord I want to take a role within the Charity Committee so that I can help the community whilst also developing my skills
The company charity committee is growing and I hope to be a significant part of it's development. I will organise, attend and drive meetings
As you can see from the points above the board is a continuation of the good habits expanding where possible. Adding more changes over time to my current foundation will allow me to progress at a manageable pace. The blue shaded areas show where progress has been made and mark a direct continuation from the previous sprint.
Hopefully I'll have even more updates for you and awesome progress as the second sprint progresses.
