Everything I’ve seen in the last decade around agile development and transformation is driven by cultural norms on teams and in challenging those – looking beyond our boundaries and challenging our current reality to see what’s out there.
The link to Soylent Green is pretty tentative but it’s a great quote! I’m sure if I spent more time I could find a mountain of philosophical links but it’s Sunday and I’m off to cut the hedges in a minute.
Despite all the practices & tools, Agile is people.
“That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.”
Not mine but this resonates strongly with my experiences. I’ve seen varying levels of agile interpretation including this during my career so far. (By contrast, the team closest to the original principles that I worked with hadn’t even given their working practices and culture a name.)
The sad fact is that it’s all too easy to fall into the checkbook agile, control & distrust trap in large organizations. What I like about this spoof is that it captures Ron Jeffries thinking from this article in a concrete and direct way that even the most disconnected exec should recognize what their teams are doing wrong.
It also uses a subtle but powerful tool that makes this worth paying attention to rather than just reading, chuckling and inwardly despairing.
In trying to understand what you should do it’s important to understand what you should not do. The original manifesto is vague. Many of the myths that cause execs to distrust agile when they first read the manifesto are made manifest due to its vagueness. Similarly, developers that see a get out of jail free card on having to do anything but cut code in the manifesto are able to do so.
The negative ad-libs at the end of each point in this cynical version provide a clear “bad” marker; a new, tangible triangulation point to avoid.
What we need are equivalent “good” triangulation points based on business reality for large-scale software development rather than a noble vision so that we can help our teams and managers do the right thing.
A couple of years ago a friend said: (I’m paraphrasing here)
My team are paid a huge pile of money to do nothing most of the time.
As an analysis team for a financial institution their goal was to be immediately available at the first sign of an anomaly in the system. Like every other good analysis team in the city, their goal was to identify and find a means of exploiting the next new anomaly before anyone else in the world did. When the rest of the world catches up, their edge is lost – until the next time.
Many times I see organizations saving pennies on billions of dollars of revenue to ensure they keep their teams “busy” or “fully utilized”.
Unless money really is that tight, staff up your teams or balance your investment portfolio not just to deliver your current needs but also provide sufficient capacity to be “ready to serve” when the next anomaly hits your market.
When your project goes wrong because you’re dependent on another team, whose “fault” is it really?
When did you start really collaborating to resolve the dependency?
Too often we throw our problems over the wall and blame the people that aren’t there to catch it for our own laziness.
Think about government lobbyists – they spend their entire time fighting for what they need to achieve…
If something is that important to the success of your goals, why aren’t you sat next to the people you need it from making sure it’s on the top of their priority list too?
YOU ARE RESPONSIBLE FOR YOUR OWN COLLABORATION FAILURES
Last year Chris Matts wrote an insightful post reflecting on the Agile Manifesto and business analysis. At the time it sparked some creative thinking but I didn’t turn it onto the right words.
Now I have them.
Writing software is just a means to an end. Our customers and users don’t always want software (with the exception of games). They want to be able to achieve something and fulfil their role.
Software was developed to help us achieve things in more effective, efficient, accurate ways. We have CAD tools because it’s seen as better than traditional draughtsmanship. We have Financials applications because it adds more value than traditional double-entry book-keeping. Software is written for commercial fighter aircraft because we made them too complicated for people to fly alone.
I could go on…
Remember you’re solving someone else’s problem or making someone’s life easier or safer, not just writing software for the sake of software.
The next time you think about adding a speculative “neat” feature or idea to the backlog, think about who will actually get value from it.
Admittedly, sometimes it might just be to tick the box on an RFP in which case your investment should be lower than if you’re delivering for real end user value but there is business value in doing something.
I’ve been working through David Anderson‘s last book; “Kanban
When taking a lean approach to software development you need to focus on value-add activity. David’s acid-test for this is very smart – I paraphrase below…
“If it’s really a value-add activity, then you should be striving to do more of it”
Now, consider this. Are we writing code or delivering working valuable software that solves a customer or user business need?
Some of you may have worked in organizations that considered measuring programmer performance by lines of code produced. Like all great metrics, there are some fair reasons for measuring LOC but with the wrong motivation, it will drive the wrong behaviour. You’ll produce more lines of code but not more value.
So…
Writing code is not a value-add activity. Producing working software that our customers and users need is.
Remember the concept of 4GLs – the more coding activity you could automate, the more real output you can get.
This approach is still relevant. Great software development teams automate as much of the coding as possible so that teams with strong domain expertise can focus on only writing the advanced business logic and don’t have to worry about the scaffolding.
For most of us in enterprise product development, global teams are a fact of life. Even if we can get individual scrum teams co-located, the chances of an entire product suite being developed in a single location are pretty remote.
Having worked in global development environments for almost my entire career; whilst there are collaboration challenges, for the size of some projects I’ve worked on you’d have similar issues with the whole team being in a single building anyway.
Rather than worrying about the issues of working in global teams we can embrace the differences our sites provide for us in order to strike a cultural balance to our development activities.
Here’s what I’d like to make the most of for starters from my own experiences…
Every culture has its pitfalls and benefits but don’t take my word for it – read a classic
One of my favourite verbal patterns is “Stop The Bleeding”. I heard the term come back to me in a management meeting last week in the right context and with the right response – Success!
I’m not exactly sure where I heard this first but it was sometime in the last 4 years. Mike Cohn references it in the context of agile testing but until I searched for the term just now I’d never read that particular article so I’m sure it’s also used elsewhere…
Name: “Stop The Bleeding” or “Plug The Hole”.
Concept: Consider the “flow” of work and issues. Many software activities generate or receive some sort of flow. Whilst you can use a Kanban approach to manage the flow, you need to address the site of the problem first to prevent it getting any worse and look upstream to consider prevention activites.
Analogies: You have a patient on a stretcher with a series of broken bones and a torn major artery, where do you focus your attention first? – or- You’re in a boat with a leak in the hull. You either stop rowing and start bailing or start rowing and start sinking. Maybe it’s time to fix the leak? Once you’ve fixed the leak, how about staying away from the rocks?
Usage: The most common times I’ve used this term are in test automation and defect management.
I’ve seen major investments in writing automated regression test suites for existing functionality or old manual tests. Skilled testers are usually in limited supply. Why are we using their valuable capacity on a static problem?
We need to take that capacity and apply it to the issues we continue to create every day – the ones where we’re still bleeding. Write automated tests for our new functionality and changes that we’re introducing right now. These become your regression tests as soon as they start passing!
In defect management a common challenge is customer escalations. These usually happen because we failed to act on a problem in a timely manner. Stopping the bleeding here means addressing new incoming defects promptly and properly. For example; try replicating issues immediately and then negotiating when your customers want a solution rather than just focusing on traditional severity / impact numbers.
Once your flow is under control and you’re working to when customers want a fix, escalations for delinquent issues will trail off fast. Now you can start addressing your other priorities. Note: The “bleeding” in this second example is customer escalations, not incoming defects – Stopping incoming defects is a subject in itself!
Back in about 2004 I was really proud of myself for coming up with the term “Egoless Development” in explaining my team’s approach to self-organization and collective code ownership. The concept was actually invented some years earlier than my use of it.
(egoless :: proud – an oxymoron perhaps?)
Somehow I doubt the author had Egoless Daily Stand-Ups in mind though…
Most of the variations I’ve seen on the 3 basic questions in a daily stand-up have a small but significant issue in common – they’re entirely ego-centric.
me…
Me…
ME…
There’s a mountain of guidelines on daily stand-ups (some of the best being Martin Fowler’s) so I’m not going to retread these. All I offer here is a tweak in thinking.
These are about the team, not you…
Consider these – either as questions themselves or in your approach to responding to whichever questions you use for sharing with the team…
How is the work you’re performing going to aid the teams commitment or goals?
As a footnote, Mike Cohn’s suggested 4th question for the scrum of scrums – “Are you about to put something in another team’s way?” works (at least in my mind) for the same reasons – it’s more about other teams than you.
The great thing about working with software development teams is that on the whole they’re a nice bunch of people who just want to get on and do the right thing.
The tricky thing in large-scale enterprise product development is that there’s often aggressive targets pushed through sales & marketing onto product managers.
A common response is to take a shotgun to the enhancement request backlog and ask for everything from the development teams and negotiate down from that point.
Craig Larman & Bas Vodde summarized this brilliantly using game theory in the second of their scaling agility books
Assuming like many large companies you’re faced with the challenge of an annual commitment-based project/backlog and you’ve whittled that down to the best you can do; chances are your product manager will come back at some point through the year having visited a customer or partner and, like Columbo, ask for “just one more thing”.
Agile development is meant to give us the flexibility to do this right?
The typical nice guy response is “well… it’s going to hurt … but we’ll try”…
Great! When your team gets kicked around the room at the end of the year for failing to meet their release commitments, I’m pretty sure I know whose “fault” it’ll be.
FrAgile
So… Time to dig yourselves out of that abusive relationship, get a backbone and learn to say “No”.
OK. Maybe that’s a bit harsh. How about…
“Sure we’d absolutely love to do that but here’s everything we’ve already committed to for you. What would you like us to drop first?”
That still sounds pretty collaborative – but now it’s on your terms.
You’ve also just highlighted that being Agile doesn’t mean not making commitments if that’s what your business needs, it means managing your customers better.
If the previous “we’ll try” conversation is the norm for your teams, chances are this is the first time your product manager has ever been put in this situation. Don’t expect it to be pretty or easy. You’ll need to stand your ground and limit the options available.
I’m a fan of visual management so here’s my take.
If you can’t get your product manager in the room, do the same thing with excel and coloured blocks representing each feature in a pipeline. Adding a new feature in anywhere in that pipeline extends the end date. If you’re on a fixed-date commitment that means something falls off the end.
Simple?
Give this a try or adapt something similar for your own needs.