Good Coaching

Coaching does not come ready with prescriptive and well-defined steps, there is no one size fits all solution. Every team is different, individuals within teams are unique and collaborate in their own ways with other individuals, within their team and without.

To be a good coach one must observe, align, facilitate, and support.

Rushing in without context and instead relying on past experience is a recipe for failure. If there were a perfect way for all teams to conduct themselves it would have been written about and sold, making the author a large amount of money and eliminating the issues that plague software development and delivery. There is no silver bullet and there is no grand conspiracy to hide the solution from you and your organisation in an effort to sell more books on the topic – the truth is these authors of popular methodologies are selling their best guess at what is likely to work in some cases based on their past knowledge and experience.

To say one methodology is the single best approach, is contrary to being agile and pragmatic.

The Mirror

When you get out of bed in the morning and throw on your clothes in an automatic fashion you might find you have put your shirt or blouse on back to front, or that the combination of clothing you have chosen doesn’t quite look right. Instead of continuing to make fashion faux pas you are likely to buy a mirror as a remedy, realising that it is not a solution but a sort of ‘coach’ to help you reflect on your situation from a different perspective.

A good coach is like a mirror, they do not come with preconceived notions about what is right or strongly held opinions on bad practices. The coach facilitates a team and its individuals to view how they do things from different perspectives, bring light on the not so good aspects while supporting the team in identifying better ways of working.

Knowing and understanding the subject material allows a coach to understand where a team is currently and what can help us improve, plateaus are inevitable and coaches are there to help us stay motivated.

Agile software development is deceptively simple. You just choose something is to build, building over a short period of time, reflect on that building period and repeat this process into your product is ready ship. If agile software development is that easy, why do so many teams and organisations get it wrong?

Most teams that start adopting agile methods generally see improvements early on, while some teams get stronger and stronger with every iteration. The majority of agile offer development teams struggle at some point early on and crumble, favouring to blame the organisation or the client, or the particular flavour of agile they are currently using. Maybe we should be doing XP or Lean instead, we all know management will support our “being agile” by ditching the methodology that is not working well for us and being fluid enough to pick up the next buzzword methodology, but they will only support that decision once.

The next time you decide to move onto another methodology management will quite rightly question, “What is going on?”. All management care about is delivery of a quality product for their client because that is precisely what’s the client cares about, I think it is important to remind ourselves at this stage that agile methodologies are for the clients and stakeholders, not for the development team. Although the development team leverages agile principles to produce and deliver a product, we deliver these products using these principles to over deliver to our clients by demonstrating that the modern way of working is far better than the old way we are trying to get away from.

“That last methodology we tried wasn’t quite right for our team, this new methodology we’re going to use is the gold standard. Lots of influential people are writing blog posts about it and it has a really catchy name.”

Agile methodologies are starting points. They are not inflexible documents chiselled in stone like a set of commandments. The whole point of agile is the try something for a short period of time, reflect on what you tried, and do something about what is not working.

Inspect and adapt

Coaching is all about finding better ways to do things and getting those new things in place, running them through a feedback cycle and iterating. To do this you need to understand the situation.

An agile coach does not have all the answers but they have the knowledge and experience of working with many different teams, with proven outcomes where a combination of observation, experimentation, and time will enable the team to hit on the right approach.

Every person in a team and an organisation is different, you cannot prescribe what should do in a particular situation. Your goal as an agile coach is to effectively read the team dynamics and understand how that team operates so you can facilitate productive growth of the teams collective output to best serve the client and stakeholders.

Showing people how to be agile isn’t enough, the principles are so simple even a five-year-old can understand. Delivering agile requires an individual or team to change the way they work and think about software development and delivery. One team may require you to actively showed them how agile practices work, while another team will benefit from you listening and asking questions instead of offering solutions. Getting a team to the point where they asking these questions of themselves is a good marker to prove coaching is paying off.

Good coaching is sequential and patient. Rather than creating a whirlwind of information in an attempt to quickly solve an underlying problem, step-by-step efforts to build a team up gradually (taking care not to overwhelm) have a better chance sticking in the long run.

Change Is Free

Change is free except when it’s not.

The primary reason that any project fails is that we cannot predict the future. What we believe to be true at this moment will invariably change over time. Change is costly which is why we endeavour to plan ahead, defining what will be done, when it will be done, and how much it will cost. We rate our ability to predict the future so highly we do not factor in the invariable change that needs to be accounted for during the course of a project.

With any textbook waterfall for project there is a Gantt chart, complete with accurate timeline and cost structure. The allure of the Gantt chart is its ability to fake confidence and successfully secure commitment to a bid, and convince the client everything is under control – it never is.

Waterfall does not plan to change and that is why it fails. Offer anyone £100 to show you a single project where the original Gantt chart timeline and the actual timeline once the project has completed match exactly, you won’t even need to reach your wallet. If an organisation is very lucky They may have one example where the Gantt chart and the actual timeline almost match, but even in such a case change has occurred and unexpected cost is the result.

Scrum welcomes change. The well-defined plan is thrown out, in favour of the more realistic and flexible roadmap. The items in the near field are more well-defined while items further afield are less well-defined, this allows organisations to focus on what is directly in front of them without losing sight of obstacles further down the road. Change is expected and embraced, we don’t lie ourselves and others that we are somehow and divine and different from the majority, capable of predicting the future Despite curiously never having won the lottery jackpot.

Iterations of 1, 2, or 4 weeks allow development teams to work on what is right in front of them without distraction, and enables a product owner and stakeholders to review what has been delivered in the last demo and better understand what should be delivered next. This flexibility allows the client to change their mind and invariably do without negatively impacting the productivity Of the team and the project. The only condition attached to embracing change is that the change should not be actioned as part of the current sprint commitment.

The sprint commitment is a collection of effort agreed to be committed to during a single iteration by the development team. The commitment is not a promise or guarantee but a best guess estimate The development team believe they can deliver based on knowledge and experience, and ultimately empirical data.

Development teams have the right to push back on and even turn away items of work that lacked clarity and definition. It is the responsibility of the product owner, working with the scrum master and overall development team, to clearly define the desired outcome and definition of done. Ensuring the development team know when a task is complete and that it will meet the desired outcomes that will best serve the stakeholders.

To change an item already committed to during an iteration Is a signal To the product owner and scrum master That there is a lack of agreement As to what is required To best serve the stakeholders. We do not have all the information all of the time and information presents itself over the course of the project, with this new information we adapt the deliverables as part of the next iteration. We embrace the change in the next iteration.

If it is found that work within the current iteration is not worth the effort based on the information available, the product owner may take the decision to remove items of work from the current iteration. This change to the current iteration should not distract from the remaining committed effort. If however the change to the current iteration is such a significant impact the remaining work within the iteration should be dropped altogether, the product owner may consult the development team and stakeholders to end the sprint prematurely and restart the sprint process.

Agencies that work with agile in mind should write this agreement into the contract with their client, stating that changes are free provided they do not interfere with the current active iteration and do not constitute new requirements not previously defined within the statement of work.

Unplanned Retrospectives

There are 2 occasions when a team is required to have a retrospective; at the end of a sprint and at the end of a project (or phase). These are prescriptive ceremonies for Scrum teams to reflect and improve.

I was asked recently if there is ever an occasion when a retrospective would be conducted outside of the traditional end of an iteration. By the book there is not, however Scrum is a methodology built upon Agile Principles and so it makes sense to be fluid in interpretation rather than sticking to hard and fast rules. By the book is a starting point for any Scrum team, the team is free to adjust their interpretation but by doing so it is likely that results may vary. It is important that a team begins from the prescription of Scrum and only over time do they add, remove, and amend ceremonies, workflows, and artifacts.

In theory you could have a retrospective at the beginning of an iteration, but this is the other side of the same coin when you consider an end of iteration retrospective – one iteration and is immediately followed by the next. What about a retrospective during an iteration?

I’ve come across a few specific occasions where a retrospective has been conducted in the middle of a sprint, in general you can have a retrospective at any time. When there is something of significance to discuss you should be having a retrospective, you are likely already doing this in a informal manner. As a Scrum team is self-organising and made up of people, conversations are common and should be encouraged. The only difference between a typical conversation and a retrospective is that the Scrum Master is there to facilitate and document findings from the discussions. If you’re a particularly good Scrum Master you will always be listening to your team, never interfering or leading the decisions but listening. Listening is the most important aspect of being a Scrum Master – you learn a lot more by letting others speak. I like to make notes throughout the sprint, documenting all the key events that occur during a sprint. With this information in hand you can more effectively facilitate the conversation throughout a sprint allowing the development team members to focus on the details of doing the work while you consider how the team works as a whole.

I’ve conducted retrospectives where a team has had problems during sprint planning, more often than not it has been a question of delivery item description quality – lack of information provided on tickets, leading to deliverables not being delivered when expected. The development team wanted to know what they needed to do to know when they had completed their work, and not find themselves constantly chasing moving targets. This particular instance highlighted the importance of locking down a sprint commitment and all information contained in those deliverables, to ensure the integrity of team velocity.

I myself have called retrospectives immediately following a daily stand up, to facilitate the conversation of seemingly innocent behaviours that may be negatively impacting the team. Watching team members type away at their laptops while their peers share information, then giving their own update to the attentive group without a hint of irony. Playing games on a smart phone, colouring and doodling in notebooks, it all comes down again to the most important skill of any team member – listening – to best serve oneself and the team as a whole.

 

Forget about 10x Individuals, think 10x Teams

The only way to get things done in the world is with teams. Everything made or developed cannot exist without a team behind the initial idea. If you could get things done on your own that make even a small dent in the universe, you wouldn’t need a team. Everyone has ideas, but ideas are cheap. Teams make ideas real and give them value.

Often businesses make the mistake of focusing on individuals in their organisation, believing performance bonuses and promotions will drive progression in the business. Managers look to individuals because they want the best people, those high performers that will garner the best results, in reality the individual is a distraction from the greater objective value.

The 10x Developer is a fanciful thing, I have no doubt there are performers out there that deliver work at a rate ten times that of some other developers, but frankly these are very very rare individuals. I’d posit these high performers are better when they perform in isolation, rather than as part of a larger team.

If you focus on individual performance you will see measures of time to deliver the same task range from 1 week to 40 years according to over 3,800 studies of a wide range of real world work. You can focus your efforts as a manager to develop individuals into high performing employees but it will take a long time and a lot of effort, you might achieve a single 10x worker – even 5x would be a worthy achievement.

Consider focusing on a team of 5 employees and achieving a 2x improvement, assuming the relative value of effort you would see a doubling in performance across an entire team that is twice the value of focusing on an individual.

Takeuchi and Nonaka shared the key characteristics of the best teams they had observed.

A great team understands the goal while being encouraged to act autonomously to deliver extraordinary outcomes. Making use of the various skills available among a team of individuals to effectively address and resolve challenges with solutions only made possible by the collective mind of a team.

Many organisations see a team struggling to deliver in an iterative manner. The first response is to throw more resource at the team to bolster the work force, but more often than not this can slow a team further. They believe hiring 3 more developers to join a 6 person team will increase velocity by 50%, maybe but more than likely the team size is not the issue.

If a scrum team is struggling to deliver on a project it may be that the team requires the support of a facilitator or coach. This is where the roles Scrum Master and Agile Coach come into play. You often need someone with experience cultivating the mindset of Agile into an organisation, particularly when it feels like the closest an organisation has got to being Agile is proclaiming, “We do Agile.”, then continuing on expecting the results without supporting the mindset.

The Agile Coach is a communicator and professional explainer, working at the development team level and the rest of the organisation. Being the champion of the manifesto so the development team can get focussed on delivering and not become disrupted or distracted by external teams and individuals.

A Scrum Master is a servant leader. I will often write that a Scrum Master “leads”, which isn’t a true reflection of the action in itself but is less cumbersome than writing, “the Scrum Master servant-led the team to a change that delivered positive outcomes”. When I say a Scrum Master leads, it is not literal and from the front but more like a therapist, planting little seeds and allowing the team to respond as they see fit by self-organising.

These roles play an important part in the visually active team members, multiplying the performance of a team or teams. You might be able to improve a high performer to a 10x individual in your organisation with a lot of effort and time.

With efforts focussed on the team in the shape of a Scrum Master and/or Agile Coach, you can improve a team of up to 9 (even multiple teams of up to 9) by as little as 2x. Resulting in a 18x team at a low estimate. If there is room to 10x a team you can see performance increase 180x in a single team unit.

This counter culture of software delivery is the secret behind teams that deliver project in weeks and months, that have faltered in the past over the course of months and years.

Understanding Fail Fast

Most conversations around developing in an Agile way are paired with the concept of ‘Fail Fast’, a trendy term to say with a boldness and confidence that warrants no retort. There is method in the madness but too often the term is thrown around with wreckless abandon in the same way that some teams find that the closest they actually get to being Agile is when the boss says, “We’re Agile”.

Fail Fast combines a negative word with a positive one, which should plant a seed that blossoms into a conversation resulting in a collective understanding and commitment to the philosophy. ‘Learn Fast’ might be more appropriate but frankly it lacks the excitement and contradiction of the former.

To Fail Fast is to appreciate and value short cycles of testing and incremental development designed to determine whether an idea has value. Should an idea be invested in further or should the idea be dropped with the organisation cutting it’s losses. The converse of moving in this way is to Fail Slow, a doubly negative connotation that actually reasonably describes traditional waterfall.

Traditional waterfall plays the odds against an uncertain future by promising delivery of an idea believed to return value in a more distant future than the short term cycle associated with Scrum, for example.

When a project fails over a long period there is a silver lining in that the project has helped an organisation Learn Slow. This is not a situation any person likes to be in.

So organisations want to Succeed Fast, but that is a devious statement to believe is possible in its own right. It promises that lessons have already been learned and a team’s information is complete and infallible, allowing the team to breeze through a project lifecycle never changing course. Course change is key in any project, only the deluded believe everything will go to plan.

No person gets in their car or on the train and knows that a traffic jam or tree on the lines will not hamper their progress. Meetings may be moved location and participants could fall ill, all information that must at some point be learned and in most cases only at an occasion when course correction must be managed to deliver. If a future impediment could be known, it would be called out in the plan before starting. Never in my career have I seen a Gantt chart that calls out even 1 known impediment before the information is available.

Markets change and competitors pivot, you do not want to be the type of organisation that like a tanker is too heavy to course correct effectively to compete with other vessels. The smaller more nimble boats are able to respond to changing conditions of the sea and weather to take learn and take action quickly.

When an iteration completes it should be seen as a positive whether we find an idea continues to make sense, just as much as an idea that needs to be dropped immediately. Sunken cost is the immediate reaction many have, believing that if we just through a bit more effort of time and money at the problem we might find the solution come into view. Rational inspection of the idea following a period of assessment should overrule emotional influences, by appreciating that the investment we have made so far was a worthwhile endeavour that would either pay towards a valued venture or confirm an idea is not worth investing further in.

Fail Fast should not be used loosely without fully understanding and clearly articulating to decision making parties in an organisation. It sounds trendy for the times but it is a buzzword on its own that should be used as a jumping off point to discuss further and gain buy-in from stakeholders before diving in. Manage expectations because nothing comes for free and people don’t mind bad news so long as they know about it at the earliest opportunity and not at the last minute when there is no time to change course.

Scrum Is All About The Customers And Stakeholders

Scrum consists of principles, roles, ceremonies, and artifacts, which are elements focused heavily on the development team and day to day activities. Customers and

Stakeholders and customers may simply contribute with needs, wants, and feedback but Scrum is all about delivering for the customers and stakeholders.

Scrum is an organisational change designed to serve all the way up the chain from the basement where the hands on work is being done, all the way up to the penthouse offices where decision makers and end users meet to assess and utilise new developments.

The most powerful aspect of Scrum is showing the actual product to stakeholders and customers. Scrum is a bold method for any organisation to embrace, or even consider, the concept of no promises of deliverables and deadlines met before a period of work has been paid for and completed. Stakeholders want to know what they are getting and when, before they sign on the dotted line or hand over any cash, traditionally stakeholders like to be promised something will be delivered on time and at a set budget, based on the guess of a salesperson solely focused on winning the contract.

Most organisations that are introduced to Scrum have come from the world of Waterfall project management, frustrated with the broken promises and failed delivery. Scrum is often met with skepticism as clients reasonably cannot believe a smaller team with a slimmer budget can deliver more and sooner than a larger and more expensive team can.

Scrum is built on the premise of iterations that each conclude with a potentially shippable version of a product. Presenting more graphs and charts to an already skeptical client would only make a client more suspicious that something was afoot, while Scrum offers something more valuable than these inconsequential distractions – a working product. The power of the demo allows development teams and stakeholders to meet on a regular basis to share progress and ensure direction is maintained and adjusted as necessary.

Scrum relies on a period of effort to identify a teams initial velocity, followed by a number of iterations and team reflection to identify areas where the team can increase velocity and accelerate performance in delivery. The initial sprint allows a stakeholder to see how productive a given team is, and the sprints that follow should show a change in velocity with each iteration giving a more accurate overall picture of when a product is likely to be delivered.

A little bit of patience and investment is all that it takes to assess whether it is worth continuing to fund a development project, and a far better model than the traditional ‘hit and hope’ where the entire project is funded and committed to in the belief that someone can see the future.

Scrum is for the stakeholders, it is not designed for the developers. Developers use the method to better serve the stakeholders in regular assessment check-ins where stakeholders are given the information available at the time to make decisions going forward.

To Improve You Must Regularly Assess And Change

Waste is produced as a by-product of the effort that goes into delivering software. Like a vehicle working against wind resistance there is always room to improve the aerodynamics of the vehicle to reduce waste in future. Vehicles are constantly evolving to sell more to consumers but also change because manufacturers recognise and are honest about where effort is being wasted.

Successful teams operate on a honour system whereby regular check-ins to reflect on past performance are conducted. In these check-ins there is a protected atmosphere for people to openly and honestly raise points and discuss opinions, this is an exercise designed to reduce the fear of repercussions of going against the grain in an effort to deliver a greater performance for the team and the larger organisation.

These check-ins consist of multiple difficult conversations that would otherwise be avoided by the majority. While new participants may find this approach uncomfortable initially, they typically warm to the bonding experience, realising that all participants have the same ultimate goal to further the team performance and deliver a higher quality product in the shortest period of time possible.

Teams where waste persists over weeks and months will find that they are missing an opportunity to be open and honest with each other and themselves to better the team and individuals performance.

Waste exists everywhere and will only grow if left unchecked.

A cell maintains a state comprised of costs and benefits to the cell, a balance ultimately designed to keep the cell alive. There is no change to the cell without the injection of energy. The injection of energy into a cell creates a turbulent environment for a period of time followed by a new maintained state. The new maintained state my be better or worse, but the important aspect of this interaction is embracing and challenging the injection of energy into the cell as an experiment to test if this change will bring a positive accepted version or a negative rejected version.

If you want to maintain a running distance time or a weight lifting personal best, you change nothing in what you have already been doing. If you want to improve you must change something. If you want to improve effectively, you reflect and assess all options before deciding on a specific targeted change. If you want to appreciate value from a change you must measure over a period of time to assess positive or negative value as a result of the change applied.