Guest Article written by Graham Holden – here’s a little something about him in his own words:
Graham describes himself as a Programmer, Scrum Jester, Shantyman.
Has been working within the internet industry since 1997, for a variety of organisations. Has a passion for programming and helping teams become effective.
In Peter Greys Book – Free to Learn (thanks Tobias Mayer (https://tobiasmayer.uk/) for recommending this), he emphasises the importance of Play for children’s learning and development. As a parent, I’m often conscious of not interfering in the play my children embark on. I’ll be present, so that if they need me for anything I can help – but I like to let them get on with things.
Peter Grey outlines Play as the following :
Play is self-chosen and self-directed; players are always free to quit.
Play is activity in which means are more valued than ends.
Play is guided by mental rules.
Play is non-literal, imaginative, marked off in some way from reality.
It got me thinking about how, when I am programming for “fun” it’s actually me “playing”.
I feel that the 5 “rules” above could be adopted within organisations as a framework. Some might say business is a serious thing, and there is no room for frivolity. But what a lot of us have forgotten, is that as children when we “played” it was serious. When you are in the midst of it, play is all consuming – it is an example of a perfect state of “flow”.
I would encourage organisations to adopt the framework to help teams use play for personal development and learning. This would be a great first step. In the past I’ve been involved in some interesting breaks organisations have put on, these have been called “hackathons”, “hackdays” or just “learning days”. The most successful ones have essentially followed the basics of the framework outlined above.
The Teams chose what to work on, and could switch to other teams if needed.
The experience of the day and the activities trumped the actual end results.
The teams got to work how they wanted, with what they wanted, and produce whatever they wanted.
The teams could work on whatever they liked.
The teams had very little pressure on them, there were no KPIs.
I believe more and more organisations should be adopted playfulness at their core, and we can have a playful movement for product development.
The only time “Documentation” was ever mentioned in Agile (aka in the Agile Manifesto) is in this statement –
Working Software over Comprehensive Documentation
Followed by a very important warning which many manage to neglect – “That is, while there is value in the item(s) on the right, we value the items on the left more.” From that, unfortunately, a ludicrous idea of not documenting at all has been generated over time.
Still a Radical concept!
Being part of many debates over years on this topic, it’s obvious how this area of the manifesto is less explored. Which is why Business Analysts and Product Owners are still wondering when to document in the Agile way or should they do it alone. Collaboration is key.
Sure – BDD helps us document user stories with collaboration and help create the Acceptance Criterion for planning discussions. Some have successfully established ATDD which helps in writing failing Acceptance tests and creates an exceptional red-green-refactor cycle similar to TDD.
BUT
Among all these, a developer still wonders WHEN do they document the intricate details of the technical architecture, necessary information about a dependency and system designs while supporting “Technical excellence” without which no one can really become agile. We can tell each other that TDD helps us in focusing continuous attention to architectural detail, but how many developers actually use it and writes a test before each line of code.
There are many cases where the product documentations are nowhere to be found as the developers were told during planning – “We are now doing it the Agile way and all you will get are a bunch of statements written in Gherkin syntax.”
Agile Principles clarifying the WHEN
#2 Welcome changing requirements, even late in development.
We are seeing changing specifications in a weekly/monthly basis. Based on the type of business it’s highly likely to see changing expectations on a daily basis as well.
Can we really document anything before knowing what to build? Give it a deep thought.
When we talk about User Stories – most popular technique for specification gathering – we are not documenting a requirement. We are starting of with WHY, the least amount of known high level outcome, with or without knowing how the output might look like.
If a team never documents anything else other than the stories, that’s when it starts getting impractical with a huge risk to quality, understanding and sustainability. Documentation is required.
#7 Working software is the primary measure of progress.
Traditionally we have learned to document first as we used to plan heavily to begin with. We know how that’s against agility according to Cone of Uncertainty. We can never know about a feature/specification well enough when we start of. We learn through early feedback on iterations that can generate enough discussion.
Reason why we should build a piece of software first based on high level WHYs and review how it may look like. Once confident and final on a characteristic or functionality, then we should document.
Only document to record evidence of a built feature which is accepted.
#9 Continuous attention to technical excellence and good design enhances agility.
With even changing specifications on continuous feedback, we need even changing updates on the documentation in real time. Documentations essentially should reflect current state of affairs rather than what we hope it could be.
When working in huge organisations where a single monolithic code base is being used and updated daily/weekly by many many developers, that’s how chaos starts. Documentation should be in codes – true. It is also true that not every developer are capable of doing it as we hope they do. If they can’t in the code, make sure they do anywhere else that can be shared and available for everyone.
Duplicate documentation is better than no documentation, as long as they provide the same recorded evidence.
Conclusion
Therefore, the original manifesto statements about “.. over comprehensive documentation” actually translates into the following:
First build a working piece of software and then focus on documenting how it was built and what it does, for shared understanding.
Time and again we hear professionals talk about empowering a being and how it’s the right way to go. How empowering a gender, race, team member or an organisation helps in improving accountability, ownership and peaceful collaboration. How this makes a robust community of respective subject matter to cohabit with shared goals.
Love the idea, it’s marvelous to see many people are embracing these great ideas. With that in mind, I asked handful of them –
How do you empower someone or a group?
Majority of the replies had a short pause, usually with a raised eyebrow, followed by a somewhat vague response like “By giving them chance to see the big picture, allowing them to contribute to the greater cause, authorising increased accountability/ownership and removing anything that blocks them”.
Seriously? Isn’t that what we should be doing anyway?
Technically anyone who is claiming to “Empower” someone is not really doing anything productive. Rather they are stopping their own unproductive interference. They are simply backing down from where they shouldn’t have been in the first place and they are taking credit while they do so. *Mind Blown*
Truth you came here to find:
The ONLY way to empower someone, is to stop dis-empowering them.
And stop taking credit while doing so. If we do, we are again not really giving them the credit they deserve while we steal the attention.
A person/group can be “Empowered”, only if they want to be!
The notion of empowering a being or a group also creates an illusion that it’s in our control. Sadly it isn’t. Fact it, if a person/group doesn’t want to be, we cannot really make them. It’s a personality trait where some like to do what they have been told.
What sort of person wouldn’t want to be empowered you ask?
“I did what I was asked, ask X who owns it now”. Silos – yes, some do love it and it’s all personal.
“Trust me I want to help but last time when I tried, your manager turned on me and requested me to mind my own business” – Fear of rejection.
“I told you this wouldn’t work. I can help you if you like? No? Alright then” – Ignorance of Skilled opinion over superiority.
“No, don’t want to get involved again. Last time I made a mistake and it affected my bonus. It was not even my domain of work.” – Outdated and demoralising KPIs
What can we do about it? Surely we can do something to Empower as Leaders
There are many ways obviously. I have found the following are good enough to start with –
Give them an achievable goal and back off. Support and Serve. Delegate and show trust. Allow failure that can be reversed. Make sure they understand they failed and ask them what they learned from it. REPEAT.
Find out what the impediments are and why can’t they remove it themselves. Let them try. If they ask for help, without passing a judgement first sort it out. Revisit on how much more we can/should do to remove the blockers in future. REPEAT.
Tailor our KPIs based on Team goals over individual performances. If we really care, let peer pressure handle it and monitor how are they performing as a team.
And yes, we should stop empowering people or tell ourselves that we can somehow.
As leaders, create a sustainable culture where people can Empower themselves.
**Spoiler Alert** – If you haven’t seen the 2017 Justice League movie, reading after the below introduction may spoil it for you. It’s important to go deeper in the story to explain the intended purpose of this article.
Zack Snyder directed Justice League, released last year, is a great example on my team building workshops. Although, IMHO, this is not the best DC movie ever created in terms of mediocre script, predictable plot, over-hyped and overwhelming special effects. My complain is more towards the movie itself not the team. Only good part of this movie is, the absence of Superman – the humble man of steel. Usually, his presence is counter productive in strategic situations that need true leadership like Batman & Wonder Woman.
Not everything needs power, sometimes it’s about tuning down, so your team members can rise.
Most important fact we can learn from this movie – what happens when your most powerful member of the team aka Superman, gets “Hit by a Truck” or in this case already dead. By the way, this was apparently the 2nd most expensive movie ever made.
Single Point of Failure? – Guess What!
Detailed plot can be found here but I will only highlight the part that is relevant to our topic of discussion today.
Relevant Plot – The movie only shines for like 5mins when a zero memory Superman is resurrected. A small mistake by Cyborg’s reactive weapon angers the man of steel and the wrath of Superman begins when he alone dominates every member of the league and almost killed Batman with a pinch. Thankfully the contingency plan pre-calculated by Batman saved his own puny human arse.
Enjoy the moment below:
We all have seen a Superman in most teams; without a plan B when they turn hostile.
Let’s give you an example that might relate to our profession.
Think of a person in your software development team (or any team) – an exceptional developer with a plethora of domain knowledge is being “Productive” with his/her headphones on. He/she might also be known as a “life saver”. You ask a question and most probably get all your answers and your problem is sorted. The rest of the equally competent new team members have potential but lacks the domain knowledge collected over years. But it was never shared neither there are any documentation anywhere. The superhero believes he/she is too busy and someone else should do the useless documentation while he/she can “Do Some Real Work”.
Now imagine the below 2 scenarios when that person becomes the bottleneck –
1) When the Superman is “Hit by a Truck”
Now, one unfortunate day that awesome developer calls in sick before a product launch. After hearing that, if you don’t feel a chilling flow of blood running down your vein right now, possibly in the stomach, I have no words for you. It’s hard to even write about it as an example, as it’s so common. The next thing we know, the product launch is cancelled, stakeholders are furious and our lives are hell.
So what do we do? We call that same person, apologise for calling when he/she is actually unable to stand, requests him/her to connect to VPN and troubleshoot the issue. In most cases, it doesn’t get resolved and we are all in a over-salted pickle topped with habanero bits. Like what happened in the above movie. Superman is dead, so the world is doomed as we were relying on him too much the whole time and never thought of having a Justice league until the shit hits the fan.
2) When the Superman becomes hostile
The person isn’t sick but need a raise 😉 for obvious reasons. Performance review time –
Manager: As you know we didn’t make any profit last year, so no one is getting any raise this time. Not even me.
Superman: It’s not fair. I have been working hard, more than anyone else in the team and usually I am the only one on call even though I never get paid for those live issue troubleshootings. No one else seems to do that neither are capable to do it.
Manager: Well, yes that is true but you never wanted to document anything, pair with them or taught them how to do it either when they asked for it. I understand you are over stressed sometimes but it is because of the unshared knowledge.
Superman: When do you expect me to do it? It’s a 5mins thing when I do it, it’s 1hr when someone else do it. Are you saying you rather wait for an hour to get a live issue looked at or even fixed? Anyway, I will need that raise unless I will have no choice but to leave. I always help out when the company needs it, I deserve it.
Can you blame the superman in this case? Especially when he/she has a point.
Superman will never ask for help !
What we should ask ourselves:
Why wait for that moment to come? Why not be ready for a moment like this?
If you have been to this situation, the first thing you ask – “Only if we had someone who knew a little bit of this person’s work. Doesn’t have to be as efficient but to do the job in anyway, a quick fix” We have all been there and pulled our hair out.
The trick is to not tolerate a superman like the above. It may sound weird, why would anyone not want a superman in the team? Well a Superman is only necessary for short term benefits and when we keep repeating the behaviour and tolerate a dysfunction, no long term benefit can come out of it. Also it’s not really good for the Superman in the team which the person may never realise.
The reason a person tries to be/stay a Superman is to create a bottleneck so his/her presence is felt for personal gain, like the salary negotiations or promotions. There are some who don’t do it on purpose though, they simply are not team players and would rather do anything asked without even thinking if it has any business value at all. These members hinders creativeness among other team members who are equally capable but have their hands tied. On above scenario 1, no one wants to work and that’s their punishment if they are doing it on purpose.
In some cases, the person who is a bottleneck may be an introvert or very shy. it’s very common among developers due to the profession. Hence they may not even ask for help even if they know they need, making themselves overstretched in daily tasks. Eventually on one day this shy person won’t be able to cope and simple resign.
Create your Justice League before the Superman dies or turn hostile. Shared skills & knowledge are the key to crisis management.
Some posts are too valuable to just stay as a post, it needs to be documented for everyone to read atleast once. When you ask for a clarification from the Agile community, they never disappoint you. Hearing things like “Training and Coaching are the same” or “My mentor is <an influencing personality who died a century ago>” – I started to question my own understanding of what they really are. Have I been thinking wrong the whole time?
So, I decided to throw the question out in public and let the community decide and help me restore my faith on the differences between (an Agile) Mentor, Trainer and a Coach. I have managed to categorise them in 4 parts to narrow down any duplication as follows-
A simple and effective visual to settle the Debate
Julie Hendry wrote about above – “As a coach you can be called upon to take different roles … much like a consultant ..here’s something from Jerry Weinberg that helps describe the stances I use in agile coaching practice…having said that training as a part of coaching practice doesn’t replace the need for formal trainers in my opinion.”
To this Paul Boos‘s view was – “… these are all potential roles a coach can take… And I am thinking a very different model from most. I think where the responsibility of delivery and responsibility for improvement are the axes… This would be 1/3 of the roles one might take on as a coach… Oh wait coach isn’t a role of a coach (no recursive refs), so 2/9….”
Clear Explanation by Community members
Rick Waters decided to clearly distinguish the roles in a “Lucid. Brief. Practical” –
“Mentor: Did you see what I did there?… Trainer: This is what you could do there… Coach: Do you see what you did there?… Guide: What you might see over there is…”
“Coach: What do you feel happened? Or What else would you consider doing? And I would add: 4) Agile #Facilitators. Coaching is a skill set on its own. Learning agile doesn’t teach you all the coaching mindset and skills required. I had not realise how much there was to coaching when I went through CSM CSPO…”
Sanjay Kumar wrote – “Trainer helps trainee gain new knowledge. Mentor helps mentee acquire new skills. Coach helps coachee explore and enhance their potential.”
This out of nowhere opened up a large can of worms which I wasn’t even thinking about while finding the right answer.
Kevin D. Martin described how consultancies are using the Pyramid scheme and these roles to harvest top salaries –
“Yes! One Agile Poser gets a gig, then brings on more agile posers to carry the water, skimming $$$ of the top. Classic mob business model.
Based on my experience 80% are Agile #Posers, until they are discovered to be none of the 3 categories you listed. Then they are Agile #Available for next robbery.”
The Certification Business
3 very interesting comments caught my eyes and changed the way I looked any certification business exists in the world today, not necessarily in Agile community.
Murali Varadarajan started it by saying – “It starts with the certifications model on who can sell, resell or receive a paper. Check the model of any popular framework.”
Jonathan Kessel-Fell replied – “You see a prime example of this within Agile through PSM / CSM or DAD / SAFe. One you can self study, discuss in a group and gain for a one off payment of $150. The other has a huge sales team, you have to pay for their training and have to pay an on going fee.”
Julie Hendry extended the fact by saying – “I don’t see it as any different from ITIL, PMI, CMMI, any vendor certifications… most certifications are a commercial venture not a learning service. And folks eat it up – providers and customers!”
Mentors, Trainers and Coaches – Take “Agile” out of it
Reading all the views and analysing the outcomes it was clear that a Mentor, Trainer and Coach have resemblance on any industry and not just in Agile community. We have a tendency of adding “Agile” to everything which automatically seems like unique but it isn’t.
So Tom Mellor decided to finally explain the way I learned it to begin with – “There are people who understand agility and mentor others in understanding it. There are people who understand agility and teach train agility values, principles, practices and thinking, and guide people in understanding agility and practices. There are people who coach people to use their knowledge of agility and practices more effectively and become more proficient in agility.
So, there are mentors, trainers, and coaches who understand agility and help people understand it. I don’t believe there are agile mentors, agile trainers or agile coaches.”
If you don’t believe that non-collocation is a challenging impediment, here are 3 videosto prove that they are.. ALWAYS.
Emails in Real Life
A Conference call in Real Life
Oh you want to do a Video Conferencing? How about all other participants?
You having a lightning fast internet connection doesn’t help remaining participants with speed as low as 2Mbps or worse.
Watch this:
A Video Conference Call in Real Life
Let’s look at the Solutions, to make it work !
Preserving Normality When You Can
Stay in contact
Talk about the mundane, little things
Visit Often
Get to know each other
Remember non-collated team members are humans
Support each other, even over the distance
Create trust
Be committed to each other
Don’t do anything irrational just because you’re angry or upset about something they’ve said or done
Doing Things Together and Bonding
Share something
Do the same things at the same time
Learn together
Make each other feel special
Pursue common interests
Create connection
Setting Expectations and Boundaries
Discuss the nature of your relationship
Talk through doubts, uncertainty, and fear together.
Remain positive.
Have reasonable expectations.
Truth about this Article
Being non-collocated is a challenge and is a reality that we all have to face in this digital world. A long distance relationship have very similar impediments but because we give a shit and we love that person, we try our best to maintain it.
The truth about this article is –
ALL of it’s content are copy/pasted from this Original Source.
This original article is about “Long Distance Relationship“ and how we can do our best to keep our loved one closer. After all, that’s all we can do to maintain a healthy relation.
Non-collocation is an Impediment with solutions, exactly like… Long Distance Relationship !
Thankfully, we already know how to deal with those impediments from our personal life experiences. Apply them. The goal is to remove those impediments gradually so the long distance stays a temporary work around. Please don’t make the mistake of asking people work in non-collocated teams for too long.
1 Rule || Simplicity 