Category Archives: People

Express Your Real Motivations

Posted on by
3
Reading time ~ 2 minutes

Hidden agendas make you unpopular, especially those that are poorly concealed.

Everyone has an agenda. I prefer mine open and public. Some may try to take advantage of that but most will respect it…

Some time ago I attended a session with a team where there had been some communication challenges. The team’s normal very tight, cohesive ethos was fraying.

As a globally distributed coaching team they’d arranged to co-locate for a week to bash out a few things and generally get together before returning to their usual sites.

Dinner and a couple of beers into the first evening together and the team spirit had started to sparkle again – recognizing each other as friends, not just colleagues. The hint of political undercurrent was still gnawing at the edges of the smiles.

Into the second day and one of the very perceptive team members called a halt to proceedings.

My paraphrasing of the conversation…

“OK, time for a break. Before we go on, let’s catch up with each other for a bit… …why are you really doing this job, what’s your motivation – what’s your angle?”

This team knew each other well enough to already know the answers but actually calling them out publicly in front of each other was a new step in uncovering potential hidden conflict.

Because the team ran on trust and acted as a balanced cast (I’ll write about team casting in future); everyone acknowledged and accepted each others’ motivations knowing that despite being potentially sensitive they were honestly and openly given.

Even better, they discussed how each other could support those motivations.

The politics and tension were gone.

Earlier this week I watched someone with a blindingly obvious personal motivation attempt to leverage it in front of a smart bunch of people who were mostly there for related but different reasons. Rather than a public calling out, it was handled through amiable debate over a beer later but everyone in that following conversation recognized the unspoken calling out had been made and started trying to re-engage and collaborate.

Or at least I hope they did

In keeping with the spirit of this post I therefore share my own agenda…

  • I’m naturally creative and like to share
  • I seek personal but usually not financial reward
  • I want to be recognized for “good” things

I strive to make a positive difference by sharing my thoughts or observations and by participating in conversation. I seek personal reward through constructive intelligent feedback, good friends and good company.

Distributed Management and Work-Life Integration

Posted on by
Reply
Reading time ~ 4 minutes

This was posted on my office wall recently…
Dilbert.com

It brought home what the last decade of international teams and ubiquitous business email access has achieved for many of us software professionals.

Since the late 1990’s I’ve worked in globally distributed or virtual teams. There’s a huge amount of positive things to be said about the working experiences I’ve had with these teams over the years.

  • My cultural boundaries have stretched
  • I’ve had opportunities to work with great people all over the world
  • I’ve learned a mountain of cool stuff
  • I’ve met hundreds of new friends
  • I’ve visited amazing places
  • and…

…

  • I’ve left my family at home most of the time.

Sadly small children and transcontinental business trips don’t really mix. My family have been incredibly tolerant and I always look to bring something back for them. They have a pretty tough ride but they support what I do and I appreciate their patience.

However…

With teams in the UK, India and the US there’s almost always a full working day of support, conversations and questions that happen outside the normal working timezone. As the pressure to deliver and support these teams has increased I find myself checking my work mail when I should be attending my family.

I recently reached the point where I was clearing my emails down during public holidays so that I could filter through and achieve something when I got in the following working day.

I check my email during breakfast at 6 or 7am and reply to things that came in during the US evening or India morning.

I commute to work and check my mail again to find another series of mails from India and a few UK early starters.

I check my mail when I get home from work to respond to anything urgent that came in during my commute.

I check my mail before bed in case there’s anything new that will derail my plans and priorities for the following day or that I can respond to before the US working day is over and 24 hours are lost on a decision.

(I also occasionally make time to write this blog, enjoy my family, study and maintain the house)

If I don’t clear my morning and evening international backlog my day job doesn’t have time & space to get done but this is all at the expense of other parts of life.

So how do I get things back under control?

WIP Limit vs Buffer Overrun

Here’s where Scrum, Lean & Kanban meet personal time management…

Set yourself a WIP limit. When that’s full, decide what doesn’t happen or has to be traded out. If you don’t make a decision, something will fall on the floor and chances are you’ll have a pile of half-done stuff. (a buffer overrun).

Build a visible backlog and keep it groomed. When new work comes in, prioritize and size it. (Take a look at the Covey Matrix as a powerful means of prioritizing). If I don’t have clear visibility to my backlog of work (not just my email inbox) then once again my mental buffer overruns and things fall on the floor.

This is where my problems are – relying on my mental buffer and inbox to be my primary and secondary backlogs!

Determine how big your backlog should be and whether it should be tiered (e.g. week, month, quarter). Just like a mature agile team, don’t build a backlog that’s bigger than your planning (or thinking and coping) horizon. If it’s important it’ll come back when you have the capacity.

Next, just like your agile projects, get your backlog visible. When new work comes in, take your stakeholders to the backlog and have a prioritization and trading out conversation.

Some things will have time deadlines and some of these you can’t avoid so what else has to give? If you have more items with time deadlines than you can cover, take your stakeholders back to your backlog and force the prioritization discussion again.

I recommend pipelining work into “emergencies“, “small“, and “not-small“. This is enough to provide an interesting mental mix but aim to limit multi-tasking to a maximum of one item in each area. (Clarke Ching has some fantastic insights and demonstrations on why multitasking is evil).

It’s also worth rewarding yourself. You’ll find items that fall in the “distraction” quadrant of the Covey matrix are often where some rewards lay hiding. Identify a few interesting, fun things and make sure they get some airtime in with all the priorities to pay off some of your priority fatigue.

Simple right?

OK, this won’t break the email addiction but it will help manage the personal backlog and priorities more effectively.

When it’s personal rather than a project this seems so much harder.  With all that time teaching teams to trade out and prioritize, it’s time I started to eat my own dog-food.

Epilogue: This article has been waiting in my backlog for a couple of weeks to be rounded off before publishing. Yesterday the manager I’m pairing with planted a large kanban board by my desk with a list of the top priority management goals and activities that we have on our planning horizon right now down the left hand side and the associated tasks and states all prepped up! It’s not our entire backlog but it’s well more than we can achieve in the next 2 weeks and covers all the known top priority things.

Now it’s time to start managing the load properly again.

SMART Goals and The Elephant Test

Posted on by
Reply
Reading time ~ 2 minutes

Just under 4 years ago I set myself a goal to “socialize the concept of technical debt” within my organization. I had a strategy but no visible means of measurement. When I’d achieved my goal it was obvious that I’d succeeded but I had no direct evidence to prove it. – and why bother? – I succeeded.

Thanks to Luke Morgan (Agile Muze) for the inspiration of the “Elephant Test” – I’d never heard of it until last week.

For years everyone I know has been indoctrinated into using “SMART” goals (as defined in the early 1980s). As a line manager, employee of multiple large corporations and one-time domain expert in learning and performance management systems I too bought into and supported the “SMART” mnemonic.

Here’s a challenge – try running a 5 whys exercise on each of the attributes of SMART.

  • Specific,
  • Measurable
  • Attainable
  • Relevant
  • Timely

I can develop valuable meaningful responses (not excuses) to most of these except measurable.

I’ve spent enough years working for corporations that love to measure to have a very good handle on the values and dangers of measurement. But until my inspiration from Luke, I never had an alternative.

Today I do!

Why measure something when you implicitly know, trust and recognize what you’re looking at?

The Elephant Test “is hard to describe, but instantly recognizable when spotted”.

A big leap in agile management is trust. Trust your teams to do the right thing.

  • If you trust your team to set and accomplish their own reasonable goals, you must also trust their judgement.
  • If you trust their judgement, they must be able to recognize when they’ve achieved a goal.

Measurement is the most brute force way of recognizing something – but not the only way.

Software development and management is a knowledge activity. We tacitly know what’s right and wrong and we openly share that recognition. Occasionally we choose to measure but much of the time we trust our judgement and that of our teams.

So if the team says they saw an Elephant, chances are they saw an elephant.

Or don’t you trust them?

If that Elephant happens to be that your team believes they’ve met their goal and their stakeholders agree, why must that goal be explicitly measurable?

I know when I’ve made a difference and those around me know when I’ve done a good job. That team consensus is far more rewarding and more trustworthy than preparing measurable evidence – it’s also a lot harder to game and a lot harder to sub-optimize your behavior to group perception than around numbers.

Next time you’re looking at goal setting. Don’t go overboard on making them all measurable. If they can pass the elephant test, that should be more than sufficient.

Try starting out with a clear simple vision, good direction, a suitable time window, a strategy and some commitment to do the right thing and work from there. You’ll know amongst yourselves when elephant-testable goals have been achieved (and delivered in good faith). These may also be some of the most valuable impacts your team can have.

Building a Case for Change

Posted on by
Reply
Reading time ~ 3 minutes

I recently led a short evening session discussing strategies for collective code ownership. We opened with a set of patterns and practices but the team highlighted something painfully obvious that I’d overlooked…

What’s the business value and driver behind collective code ownership. What’s in it for your product owners and customers?

So often we focus on the people barriers and technical challenges to collective code ownership without recognizing that the barriers may be organizational or financial.

This challenge happens when you attach yourself to “the right thing to do” and seek to progress without recognizing that the population you’re likely to be working with will fall across a spectrum from complete support, through “don’t care” to disagreement and dissent.

If you want to pursue a strategy for collective code ownership, step back and work through the following questions (some of these are hard – consider starting by brainstorming with a small supportive team):

  • If we just got on did it, would we be successful?
    • Yes – Great, you’re working with a team and business that “gets” this or trusts you to do the right thing. You could stop reading here, but you might want to skim this to see what ideas & thoughts are triggered.

    • No – OK, you’re part of the more normal population (for now) read on for some ideas. You might not need to cover all of the following (and if you do, it might slow you down)

Still reading? – Good!

The following apply to pretty much any change or investment program but answering them is surprisingly hard. Your context will probably differ to mine so I’ve not given all the answers today.

  • What are the top 1-3 benefits of pursuing this?
  • What are the top 1-3 costs of pursuing this?
  • Are there people outside the team that I’m going to need to “sell” to?
  • Are there people inside the team that I’ll need to sell to?
  • What are the risks, pitfalls and political or personal agendas?
  • What do we sacrifice – what’s the opportunity cost?
  • Who are my supporters and how can they help me?
  • Who’s on the fence, do they need to be involved and how can they help/hinder?
  • Who will fight against this and how big a problem is that really?
  • Do I ask for permission and support or press ahead and ask for forgiveness later?
  • Who will this impact and in what ways (positive and negative)?  **detail below

**How about those stakeholders?

For the set of stakeholder questions I suggest you’ll achieve better flow and find natural breaks if you cover positive and negative aspects for each role by “switching hats” as you work through rather than batching up all the positives first.

  • What’s in it for you and what’s the down side?
  • What’s in it for your peers and what’s the down side?
  • What’s in it for your boss and what’s the down side?
  • What’s in it for your team and what’s the down side?
  • What’s in it for your business and what’s the down side?
  • What’s in it for your users and what’s the down side?
  • What’s in it for your customers and what’s the down side?
  • What’s in it for a product manager/owner and what’s the down side?
  • What’s in it for a project/program manager and what’s the down side?
  • What’s in it for an individual team member and what’s the down side?

Wow! that’s a lot of questions.

As I said – you might not need to answer all of these and you really don’t want to have to write them all down but it’s worth spending a few minutes or hours considering these if you’re planning to invest your time, effort and credibility in something you believe in.

Beyond everything here, I also recommend a read of Fearless Change to help you on your way.

Patterns For Collective Code Ownership

Posted on by
Reply
Reading time ~ 5 minutes

Following the somewhat schizophrenic challenges of dealing with person issues on collective code ownership, here we focus on the practices and practical aspects. How do we technically achieve collective ownership within teams?

We’re using the “simple pattern” approach again. For each pattern we have a suitable “anchor name”, a brief description and nothing more. This should be plenty to get moving  but feel free to expand on these and provide feedback.

Here’s the basic set of patterns to consider:

Code Caretaker

Let’s make it a bit less personal, encourage the team to understand what the caretaker role for code entails. It’s not a single person’s code – in fact the company paid us to write it for them. Code does still need occasional care and feeding – Enter the “Caretaker”.  Be wary though that caretakers may become owners.

Apprenticeship

Have your expert spend time teaching & explaining. An apprentice learns by doing – the old-fashioned way under the tutelage of a master craftsman guiding them full-time. This is time and effort-intensive for the pair involved but (unless you have a personality or performance problem) is a sure-fire way to get the knowledge shared.

If you need to expand to multiple team members in parallel,  skip forward to feature lead & tour of duty.

Ping-Pong Pairing

Try pair programming with an expert and novice together. Develop tests, then code, swap places. One person writes tests, the other codes. Depending on the confidence of the learner, they may focus more on writing the tests and understanding the code rather than coding solutions. Unequal pairing is quite tricky so monitor this carefully, your expert will need support in how to share, teach & coach.

Bug Squishing

Best with large backlogs of low-severity defects to start with. Cluster them into functional areas. Set a time-box to “learn by fixing” – delivery is not measured on volume fixed but by level of understanding (demonstrated by a high first-time pass rate on peer reviews). If someone needs help they learn to ask (or try, then ask) rather than hand over half-cut. This approach works with individuals having peer review support and successfully scales to multiple individuals operating on different areas in parallel.

A Third Pair of Eyes (Secondary Peer Review)

With either an “initiate” (new learner) or an experienced developer working on the coding, have both a learner and an expert participate in peer reviews on changes coming through – to learn and provide a safety net respectively. The newer developer should be encouraged to provide input and ask questions but has another expert as “backstop” for anything they might miss.

Sightseeing / Guided Tour

Run a guided walk-through for the team – typically a short round-table session. Tours are either led by the current SME (subject matter expert) or by a new learner (initiate). In the case of a new learner, the SME may wish to review their understanding first before encouraging them to lead a walk-through themselves.

Often an expert may fail to identify and share pieces of important but implicit information (tacit knowledge) whilst someone new to the code may spot these and emphasize different items or ask questions that an expert would not. Consider having your initiate lead a session with the expert as a backstop.

Feature Leads

The feature lead approach is one of my favourites. I’ve successfully acted as a feature lead on many areas with teams of all levels of experience where I needed to ramp up a large group on a functional area together.

By introducing a larger team, your expert will not have the capacity to remain hands-on and support the team at the same time. They must lead the team in a hands-off approach by providing review and subject/domain expertise only. This also addresses the single point of failure to “new” single point of failure risk seen with “apprenticeship”.

This is also a potential approach when an expert or prior owner steps in too frequently to undo or overwrite rather than coach other members activities. By ensuring they don’t have the bandwidth to get too involved you may be able to encourage some backing-off but use this approach with care in these situations to avoid personal flare-ups.

Cold Turkey

For extreme cases where “you can’t possibly survive” without a single point of failure, try cold turkey. Force yourself to work without them.

I read an article some years ago, (unfortunately I can’t track it down now) where the author explained how when he joined a project as manager, the leaders told him he must have “Dave” on the project as nobody else knew what Dave did. He spent a week of sleepless nights trying to figure out how to get Dave off the project. After removing Dave from the project, the team were forced to learn the bottleneck area themselves and delivered successfully.

(Apologies to any “Dave”s I know – this isn’t about any of you)

Business Rule Extraction

Get your initiate to study the code and write a short document, wiki article or blog defining the business rules in the order or hierarchy they’re hit. This is usually reserved for absolute new starters to learn the basics of an area and show they’ve understood it without damaging anything. It is however also a good precursor to a test retrofit.

Test Retrofit

A step up from business rule extraction whilst delivering some real value to the team. Encourage your learner to write a series of small functional tests for a specific functional area by prodding it, working out how to talk to it, what it does and what we believe it should do. Save the passing tests and get the results checked, peer reviewed and approved.

Chances are you might find some bugs too – decide whether to fix them now or later depending on your safety margin with your initiate.

Debt Payment

After a successful test retrofit, you can start refactoring and unit testing. As refactoring is not without risk this is generally an approach for a more experienced developer but offers a sound way of prizing out functionality and learning key areas in small parts.

This is also a natural point to start fixing any bugs found during a test retrofit.

National Service (also known as Jury Duty)

Have a couple of staff on short rotation (2-4 weeks) covering support & maintenance even on areas they don’t know. This is generally reserved for experienced team members who can assimilate new areas quickly but a great “leveller” in cross-training your team in hot areas.

Risks are generally around decision-making, customer responsiveness, turnaround time and overall lowering of performance but these are all short-term. I’ve often used this approach on mature teams to cross-train into small knowledge gaps or newly acquired legacy functional areas.

My preferred approach is to stagger allocation so that you have one member on “primary” support whilst another provides “backup” each sprint. For the member that covered primary in sprint one, they’re on backup in sprint 2. (expand this to meet your required capacity).

3-6 months of a national service approach should be enough to cover the most critical functional gaps on your team based on customer/user demand

Tour of Duty

Have your staff work on longer term rotations (1-6 months) working on a functional area or feature as part of a feature team. This couples up with the “feature lead” approach.

Again, this is an approach that is very useful for mature agile teams that understand and support working as feature teams but can be introduced on less-experienced teams without too much pain.

The tour of duty can also work beyond an individual role. For example a developer taking a 3-6 month rotation through support or testing will provide greater empathy and understanding of tester and user needs than simply rotating through feature delivery. (My time spent providing customer support permanently changed my attitude toward cosmetic defects as a developer)

Adjacency

This takes a lot more planning and management than the other approaches described but is the most comprehensive.

From the areas each team member knows; identify where functional or technical adjacent areas lay and then use a subset of the approaches described here to build up skills in that adjacency.

Develop a knowledge growth plan for every team member sharing and leveraging their growth across areas with each other. Although this is an increase in coordination and planning, the value here is that your teams get to see the big picture on their growth and have clear direction.

All these patterns have a selection of merits and pitfalls. some won’t work in your situation and some may be more successful than others. There are undoubtedly more that could be applied.

Starting in your next sprint, try some of what’s provided here to developing shared ownership and knowledge transfer for your teams. Pick one or more patterns, figure out the impacts and give them a try.

(Coming soon “Building a Case for Collective Code Ownership” – when solving the technical side isn’t enough)

Your Baby Might Be Ugly

Posted on by
1
Reading time ~ 3 minutes

Everyone thinks their own babies are beautiful. Some probably are but there are plenty that really aren’t. In fact I remember one particularly interesting comment -“ugly people produce ugly babies”

This happens in code too.

Collective code ownership has many challenges. Here I focus on the person pitfalls.

Imagine you’ve just spent the last 3, 5, or even 10 years nurturing and grooming an insanely complex (and dare I say “clever”) functional area of a product. This has been your working heart and soul for years – apart from the occasional customer to distract you. It follows your own unique,  “perfect” coding style and conventions. You’re so damn good you don’t need unit tests, you instinctively know and understand every intricate tracery and element of logic in there.

Why then if it’s so perfect are you not willing to share?

This is where “Bad Captain” starts to kick in with me…

  • Do you believe that every other developer in the building is less capable than you?

(OK, sometimes it might be true but that’s very rare.)

– That’s fine, you can peer review and provide feedback if they don’t meet your standards right? It might be an emotional lurch to start with but seeing someone else succeed and recognize your greatness must surely be rewarding right? I’ll help you if you need.

  • It’ll always be quicker if you work on it. It’s just a waste of time and effort to train someone else up.

– Sure. Except if we had 3 or 4 people capable of working on it in parallel we might get everything that’s on the wish list for it done this year and you might be able to do that other interesting stuff that the rest of the team have been playing with. In fact, I’m willing to invest if it’s that important…

Bad Captain starts to twitch…

…and if it’s not, why do I have someone who believes they’re “one of the best” working on it – I want my “best” people on my priority tactical and strategic items.

  • You’ve been doing this as your own pet-project on the side and it’s not ready to share.

– If it’s important I want a team on it. I’ll happily lobby for some strategic investment. If it’s not as important as anything else we have committed right now I want you helping the rest of the team out…

Bad Captain…

– even if you’re good, you’re not “special”, don’t expect to be treated any differently than the rest of the team.

These first reasons are almost valid. But not good enough for me. The more of these I hear the more I start to twitch, the more terse I get and the more I start to frown and tense up.

Suddenly it’s too late! Captain Hyde takes the helm!

Here’s why Captain Hyde thinks you’re not sharing…

  1. You’re lazy, you’re only any good at this one area and don’t want to have the responsibility of teaching it or learning something new that you’re not so good at. – Time for you to learn a bit about intellectual humility.
  2. If you relinquish control of this code, you relinquish your seat of power, you’ll make yourself dispensable and that can’t possibly happen, you think you’re far too important for that. – I believe in good people, if you’re one of them I’ll fight to keep you. If there’s a squeeze, even the indispensable will get the push. In fact in my experience, the all-rounders are more likely to find new homes.
  3. Secretly in your heart you know it’s loaded with technical debt, years of warts strapped onto the sides, a catalogue of compromises and mud that doesn’t mirror the patterns of the outside world in the 21st century. – In fact I could probably find something open source that does the same thing. Quite frankly it’s an ugly baby that should have been put up for adoption or surgery years ago but your professional pride won’t admit it.

Captain Hyde can’t think of any good reason other than personal self-preservation or embarrassment that someone who is a single code owner would be unwilling for other people to work on and learn their code.

Maybe I’ve just been in management too long but I distinctly remember in my early coding years a call with a colleague in San Francisco where he said:

“Damn, you’re the only guy in the world that knows this stuff man”.

– at which point I felt that little clench inside that said. “I need to find and train my replacements up as soon as I can!”

A similar counterpart of mine in the US at the same time got thrown another pile of stock options every time he threatened to leave – that wasn’t my style as a developer and it’s not my style as a manager either.

Now despite all this ranting, there is another very real problem.

Developing collective code ownership from single points of failure on complex products is time-consuming, expensive and probably not what my business stakeholders want my team “wasting” their time on when we already have experts who are “perfectly capable of maintaining this themselves”.

It’s a fair point.

With a team who are willing to share but have no slack, if I want collective code ownership to succeed I’ve got to be able to market it properly.

The Joy of Peer Reviews (Part 1 – Code)

Posted on by
Reply
Reading time ~ 2 minutes

Pair programming replacing peer reviews is a myth in the same way that “agile projects have no documentation”.

From my experience peer reviews continue to hold a vital place in agile development and software craftsmanship. Unfortunately they are often misunderstood or misapplied.

“Humanizing Peer Reviews” by Karl Wiegers is the best primer I’ve read so far on peer reviews so I’m not going to duplicate Karl’s efforts – I strongly recommend a thorough read. In fact, print a copy and give one to every member of your delivery team to read and discuss.

Like everything else in modern software development, peer reviews are a collaborative team learning experience. Reviewing code properly means both the reviewer and reviewee walk away having learned something and improved their craft.

With code reviews; beyond reviewing for functional correctness, (the simplest, most obvious and potentially quickest part of a review) there’s a selection of considerations I expect reviewers to look for. (There are plenty more).

  1. No code without tests
  2. Good variable naming
  3. Correct use of classes and interfaces
  4. Small methods
  5. Adherence to standards and conventions
  6. Style consistency across the team
  7. Readability
  8. Good test coverage from small tests
  9. Test code follows the same quality standards as production code
  10. Tests describe expected behaviours
  11. All tests pass
  12. Evidence of some test preparation to consider boundary cases, failure modes and exceptions
  13. Clear exception handing, failure modes and explicit boundaries
  14. Sensible error messages
  15. Code smells
  16. Performance risks or tuning opportunities
  17. Security or other “ility” issues.
  18. Opportunities to learn new tricks
  19. New good practices & patterns
  20. Functional correctness

Once you have cultural acceptance on the breadth of technical peer reviews develop your own checklist that everyone supports and remember the goal of a review is to share improvement opportunities, not for lazy coders to have someone else find their bugs for them or for staff to step on each other.

Now…

If you think peer review of code is problematic for your teams, I guarantee that document peer reviews will be a whole lot worse! – see part 2.

Your Leaders Are Not Gods

Posted on by
Reply
Reading time ~ < 1 minute

It’s lonely at the top, but who makes it that way?

In Large companies there seems to be a myth – often perpetuated at the middle tier – that senior leaders are somehow “gods” that cannot be spoken to or at least not in the same way as mere mortals.

The business leaders that I’ve had the pleasure of talking to have been very smart, politically astute, personable, socially aware and most of all they care what people have to say. Admittedly they’re strapped for free time but they’re still human beings.

A casual conversation, sharing of thoughts and opinions or mail exchange should be possible at any level. In fact that no-nonsense, relaxed, open and honest communication is a breath of fresh air from the political games and data feeds faced most of the day.

In any organization that claims to be lean or agile, isolating communication with our leaders to single PowerPoint slides and 2 minute bursts of data defeats the entire point of a true lean corporate culture.

“Go see” also means listen, share, learn, coach, mentor, teach, act, support and most critically interact.

Most leaders understand this (they all started out somewhere) but you may have to cut through a layer of defense to get there and re-educate along the way.

When your leaders do go see, make sure they really see and understand. It’s not all a parade no matter how your local glitterati might want to make it one.

Remember no matter where you are in the food chain, a truly agile organization values individuals and interactions.

Stop Working With Blunt Tools

Posted on by
Reply
Reading time ~ 2 minutes

Clarke Ching introduced me to a story of 2 woodcutters – one worked furiously but finished late whilst another stopped frequently to sharpen his tools and finished early.  (He tells it better than I do) – I think it’s actually based on an Abraham Lincoln quote:

“If I had eight hours to chop down a tree, I’d spend six hours sharpening my ax.”

Let’s think more about developing software the Lincoln way…

What tool sharpening should you do before you start chopping?

If you paid off or prevented some of the debt you were facing before new work started, would it enable your project to run faster, more smoothly, with reduced risk, a lower chance of defects or a lower maintenance cost?

A previous employer had a great strategy. Every new release of the product had 2 top priority named features on the priority list for “cleaning up” and “levelling up”.

Cleaning up:

  1. Get all unit and regression tests passing (and keep them there).
  2. Address all build failures and warnings (and keep them under control).
  3. Delete all functionality, code and tests that will have been deprecated for more than 3 releases. (and add alerts to functionality that will be removed in the next release)
  4. Fix all defects that put us below releasable quality before we’ve even started (and keep them there).

Levelling up:

  1. Raise the tools we use to those that are best supported, newest in the market or offer improvements to our working conditions.
  2. Raise the libraries we use to the latest supported versions and address any issues.
  3. Raise the platform versions we’ll support when the product ships and address any issues. (and remove support for obsolete or out of date platforms).

No major release started full-tilt on functional work until these were cleared.

Like all good practices, this isn’t new thinking, it correlates to 3 components of the lean 5S strategy; sort (seiri), straighten (seiton) and shine (seiso). Rather than just describing what was done, here’s some tangible benefits for the clean up & level up approach…

  1. There were no unpleasant surprises for our customers on a new release. We had a standard platform, support and deprecation policy and kept to it. Our customers liked it when we did predictable things.
  2. For the development teams levelling up was a common risk. Addressing this at the beginning of a project was a valuable de-risking activity. Where we hit critical problems, we could make clear, early upgrade decisions and where there were fewer issues we would develop full-time on updated versions throughout the project with regression on older supported platforms available from prior development cycles.
  3. Removing old parts of the product made life significantly easier for the teams. The reduced testing, regression and maintenance load allowed us to speed up development – much like scraping barnacles off the hull of a boat to help it run faster. Cleaning up also allowed us to take some sensible baseline code metrics before any new work started.
  4. Giving teams space and time to clean and level up before starting functional work had a positive impact on morale. We felt that we were trusted to “do the right thing” rather than “just ship it”. This empowered us to continue doing the right thing throughout the rest of our work.

Give your teams some time out to sharpen their tools and sort, straighten & shine the workshop before new work starts. It will make a difference to the performance of your team and the quality of the end result.

Dietary Manipulation (Part 1) – Pizza

Posted on by
Reply
Reading time ~ 2 minutes

**Note, I’m not responsible for any health issues related to over-eating, poor diet, allergies, existing or hidden conditions or the quality of the pizzas ordered in. Eating pizza during training is a personal choice.

Covering story sizing in ~30 minutes needs creative ways to get through people’s mental road-blocks.

On a pure estimation course attendees are prepared to expand their estimation skills with no “selling” needed however if it’s a small component of a multi-day “agile” course people find it hard to fit in their heads. They need to mentally accept the basic concepts and then learn by doing.

I’ve developed a novel (and not very healthy) technique for getting through the “I can’t fit it in my head” barrier.

At the start of a course; during discussions on logistics, lunch, dietary needs etc. I say to the group:

“OK, this afternoon we’ll be covering story point estimation. This can get a bit contentious for those of you that are mathematically minded…”

“…For lunch today, if you are willing, I suggest you have a large helping of pizza. Once you’re fully loaded with carbs, we’ll start the afternoon session. The estimation stuff is about an hour in – where you’ll be close to your carb peak and won’t feel like fighting any more :)”

Then I make sure there’s just over half a large pizza per person available for lunch.

This sounds bad, but it’s not mandatory and I’ve been completely honest with attendees – I’ve not yet had anyone not comfortable to eat pizza.  **(see opening disclaimer)

I’ve also quietly planted the seed that although it’s tricky and abstract, I don’t want any trouble during that part of the session.

What we’ve done is collaboratively neutralize the barriers that prevent the theory going in so that the teaching is more like osmosis. Once the basics are gently brought in with some slides, chat and rather lethargic Q&A , the teams put the theory immediately into practice on their workshop exercises.

Now they get it – but without the mental trauma!

After another day’s immersion with the points they defined during the workshop exercises marked in the corner of each of their story cards, the seeds have taken hold sufficiently for teams to accept what they’re doing and use again outside the classroom.

Never underestimate the power of food & drink when teaching and/or learning.