…or at least talk. I’m appearing at the Epicenter conference in Dublin next week. I’ve got two sessions lined up:
I was out shopping with my wife this morning. We popped into a craft store to allow her to pick up a few things for a project she’s undertaking.
I noticed this :
Which made me chortle a little. The fact that Kanban - Quality As Standard had made it into the realms of hand-crafted gift cards was surprising. Then my jaw dropped at the next card in the rack:
Wow! Waterfall and Kanban, right next to each other competing. Then I noticed this:
It turns out that nobody is buying Waterfall in the craft world. Nobody is buying it, no matter how it is packaged.
I was talking with my friend Clarke Ching today about Kanban and pull systems in general. I came up with a metaphor that we both liked and thought I would share it.
Problem : Imagine you want to get a ball of string ( your features ) through to the other side of a funnel ( your development team ).
Traditional methods involved pushing REALLY, REALLY HARD until it goes through.
Agile and other iterative methods realise that trying to force a whole ball of string through a funnel at once is madness, so they chop the string up into smaller pieces which are easier to push through.
Pull systems, such as Kanban, change the dynamic, rather than pushing the string through, they feed the tip of the string through and then pull it as fast as they can.
Which of these is best?
Well, traditional methods often cheat by mashing some subset of the string through and declaring victory. Or by making the team ( the funnel ) enormous so that you can fit a fairly large ball of string through the hole without effort. Or by minimising the features so that they’re dealing with a tiny ball of string. Or some combination of the above. I’m not sure this is ever a good idea.
Agile works pretty well, but the chopping takes effort ( iteration planning ) and consumes time. But it does break down into nice, neat iterations which provide clear points for releases, milestones, measurement and feedback.
Kanban works pretty well too, it might be slightly more efficient than an iterative Agile approach, but the milestone and release points need to be superimposed onto it since there are no natural break points.
Lean and ToC have their place here too - tools, techniques and strategies to make the hole in the funnel wider and to make sure that the string that gets through is the right string, used as efficiently as possible. Stretching the funnel as far as possible, just as I have stretched this metaphor.
I was reading through the principles page on the Agile Manifesto site today and I realised that I’ve never really been very good at one of the items.
The best architectures, requirements, and designs emerge from self-organizing teams.
I’ve managed a lot of teams, and for the most part, I’ve been deemed pretty successful. My management style was always to try to blend in with the team, to be one of them, to get people to move forwards by setting an example or by encouraging them. I never introduce or describe anyone as working for me, I always say I’m working with them or we’re on the same team. Of course, there are management activities that need to be performed (reviews, promotions, demotions, bonus awards etc), and I’m happy doing those things. I’ve never felt that knowing people, or treating them as the equals (which, of course, they are) hampered me in any way. The more closely you work with someone, the more of the real them you see. You get a better idea of their potential, their skills, their interests, ways in which they could contribute more to the organisation.
I’m actually lying when I say I’ve never introduced anyone who worked for me as a subordinate. My friend and mentor, Gerry Martin, who was instrumental in my decision to return to college and retrain in software, eventually came to work for me. Every time I got to introduce him as my minion, I got a kick out of it. But, hey, if you can’t poke fun at your best-friend, who can you poke fun at. (Sorry Gerry, you know I love you.)
My attempt at egalitarian leadership didn’t always work out as I intended. One of the things I didn’t consider, is that because I could ignore differences in organisational authority, it didn’t mean that others felt the same. This led to one incident where I upset someone through an ill-considered joke that left them feeling angry, impotent and embarrassed.
I feel that, for the most part, the people on my teams were given authority and autonomy, everyone was given the opportunity to contribute as much as they wanted or were able to. There was opportunity for decision making, direction setting, personal contribution, group collaboration and individual growth. But, were my teams self-organising? Not really. I was always there trying to guide people in the direction I felt we should be moving. Not by edict, decree or demand, but by persuasion, example and leadership. But, in the end, however gently the boss tries to guide you, you’re still aware that he’s the boss and his opinion carries more weight than merit alone. It wasn’t a democracy or a meritocracy: even if everyone disagreed with me silently or publicly, it wouldn’t have led to my replacement.
Is this a problem? Perhaps. I’m not sure what the alternative is. I firmly believe, that leadership is vital to the success of any organisation. By leadership, I don’t just mean “somebody has to be in charge”, I mean that someone has to accept responsibility and authority in equal measure and then use that authority judiciously, sparingly and only for the good of the organisation and all of its stakeholders.
Is a truly self-organising team possible in a commercial organisation?
I finished off Almost Perfect this morning and I must admit I was a little disappointed by the ending. All the way through the book I’d interpreted Peterson’s actions one way, and then, in the last fifty pages he started to spout his personal philosophy and I realised that I had been interpreting things in a more charitable way than I now feel he deserved.
One of the things that irked me the most was the section where he described how the employees had been asked to work long hours, six days a week for over a year and they’d done it because they were trying to help the company. Then he follows on with complaints about people being unprofessional and visiting the doctors or the dentists during the day. He complains extensively about anyone doing anything not directly work related during business hours - down to being angry at people for showing new baby pictures to colleagues - and then spends long paragraphs describing how productive he was during his afternoon tennis games, or how much he accomplished just by sitting on the beach relaxing and thinking.
“Hi, my name’s Pete. I’m inconsistent and unreasonable.”
I think he must have taken criticism about some of this in the past because the on-line version has a number of the later pages missing. The second-hand copy I got from Amazon was the complete text and the extra light it shone was, as is the nature of light, illuminating.
I’d still recommend the book to anyone who wants to read it. One particular section near the end of the book contained a valuable lesson.
Peterson had described their problems shipping enough copies of a new version of WordPerfect. A few years later, their next major release was due to ship, in the months leading up to their IPO. The launch went off without a hitch and first month sales were at a record level. Then they died off. The next month wasn’t much better. This unexpected, and un-predicted, drop off in sales hit their IPO hard.
During analysis of the slump, they discovered that because their distributors hadn’t been able to get enough product to supply demand after the last major release, they’d over-ordered for the release of the new product. Since they’d over-ordered, they were carrying extra stock and they didn’t need to re-order. This created a month one with unrepeatable sales, making all subsequent months look bad, and months two and three were bad by any standards.
Apart from all the usual lessons about judging sales based on fulfilment of only part of the supply chain rather than completed end-to-end transactions we’re left with a crystal clear example of human behaviour.
People will guess your future performance based on your past performance. It doesn’t matter what you say or do, a man, or a company, is judged by their actions.
Next Friday, the 29th May, Clarke Ching and I are teaching a one day workshop in Edinburgh entitled ‘An Introduction to Agile, Lean and Kanban’.
We’re charging a small fee (£30) to those who’re in full time employment: really, just enough to recoup the costs of renting the room. Entry is free to those who’re currently an ‘under-utilised resource’ (HR speak for unemployed).
If anyone is interested, please contact me at rob@
I’ve been mulling over my dissatisfaction with BDD, and I’m finally in a position to write down my thoughts.
In short, BDD doesn’t actually seem to be a coherent thing. There are many different perspectives on it, and many different tools with slightly different focusses. The only consistent thing is that the word ’should’ is required to be used anywhere that you would traditionally have used ‘assert’.
To be clear, my argument isn’t with the tools that have been developed: I’m not sure I have a need for ScalaTest or easyb or RSpec or Cucumber, but I think they’re interesting and I hope that future development will lead to something I find compelling. My problem is with the definition of BDD itself.
BDD started off being touted as a replacement for TDD. TDD was too hard, people confused TDD with a testing methodology, people didn’t understand TDD was about design, tests were too hard to read: so the BDD inventors and proponents suggested. Some of this may have been true, there are many people who fail to grasp that TDD was primarily, but not exclusively, about design. Dan North, Dave Astels and others decided that the way to reduce confusion was to change the name; which always reminded me of the way Borland decided to improve sales by changing their name to Inprise.
So here we have it, BDD is a replacement for TDD, now it uses specs and the word ’should’ rather than tests and the word ‘assert’. I thought it was a bad idea at the time because you don’t make things easier for people to understand by having more than one way to say things.
assertEquals(oneWayToDoThings(), "good"); many_ways_to_do_something shouldBe 'bad'
I have no doubt that the creators of BDD and RSpec had good intentions. I have no desire to challenge their integrity or their creativity.
As time has gone on, BDD has morphed into a creature that is neither fish nor fowl. BDD specs have morphed, in many cases, to be ‘executable requirements specifications’ which is a laudable goal, but leaves a number of holes.
If a spec is an executable requirement then it is written in customer language. If it is written in customer language then it is of no use as a tool for driving design of classes, methods, objects and functions. So, if this is the home of BDD then it isn’t a replacement for TDD it is something that lives alongside TDD. Mention this to a BDD proponent, though, and you get an argument. You can write specs that cover the same ground as unit tests. Yes you can, but what are the advantages of doing so? You’ll have wordy, obfuscated tests carrying the baggage added to make BDD more palatable for customers and, you still miss out on many of the benefits of TDD.
TDD, as a design methodology, forces you to write code that is used by two different clients: the tests and the final application. This is one of the ways that it helps promote flexibility. It gives you an early look at ‘how exactly am I going to use this class/object’. DBB frameworks don’t look or work like the code that will be calling the final code, so there really is no benefit here. Take easyb as an example, it doesn’t even use the same language as the code you’re writing (assuming the common use case of using easyb as a BDD framework for Java development).
TDD highlights pain points when writing tests, if it is hard to write a test for, your code probably needs a little work. BDD frameworks such as Cucumber, can quite happily support specs written in terms of ‘the system’ or ‘the application’ and you have to write grotesque code to make it work under the covers. This doesn’t make Cucumber a bad tool, just the wrong tool for the job of designing code.
So what is the output of BDD: User Acceptance Tests? Functional Tests? Unit Tests? System Tests? A system design? The design of individual units? It depends on who you talk to.
I’ve seen specs that are written from a customer point of view, useful as user acceptance tests. I’ve seen these mashed until they talk about an application in terms of controllers and pages and objects, making them useless as user acceptance tests because they’re not what the user agreed to and they no longer understand them well enough to re-agree to them. They’re also sub-optimal as drivers for design because they’re based on the implementation assumptions of the end user and they’re constrained to be about the subject matter that the user was originally talking about. This leaves lots of areas undefined where you need design but don’t have explicit user requirements because they just want it to work. The users will not tell you that they want to ensure that you have properly nested resource de-allocation blocks in your JDBC code because that’s not their domain. Do you need to have it? Yes, absolutely. Do you want it to work every time. Yes, absolutely. Will a badly designed solution make your code a pain to work with forever, yes absolutely.
So what happens? Developers have to write more specs, for things that users actively don’t want to know about.
I’m not convinced by BDD as a means of writing functional specifications either ( this doesn’t include User Acceptance Tests ). The best functional specs I’ve seen were elegant documents that used text, screenshots, charts, tables, diagrams, flowcharts and even embedded sound files to describe as concisely and accurately as possible the users expectations. Constraining these documents to a structured textual format is, at the moment, a bad idea. We’re reinventing Knuth’s Literate Programming ideas of the seventies, only we’re trying to impose it on clients and analysts too. There may be a future here, but I don’t think we’re here yet.
Particularly egregious offenders here are those cases where the functional specification is written in embedded strings in a document that is otherwise code. Conflating two completely different documents, and levels of abstraction into a single chimera-like whole that serves nobody well.
Ten years ago, I worked for a company where all development was done in UML and we forward generated the code from our diagrams. This didn’t work well, it was slow and painful but ‘technically’ it was possible so those in charge kept pushing the idea. Writing functional specifications using BDD frameworks is ‘technically’ possible but that doesn’t make it a good idea. Not here, not now.
We’ve learned new ways of building tools, and we’re looking for ways to leverage them. BDD isn’t AN answer, so it certainly can’t be THE answer.
David Anderson’s InfoQ talk on Kanban and software development is fascinating. In particular I liked the clarity of the numbers he produced to prove the successes of his methods. I also liked the photographs of the tracking boards that different groups were using, David’s analysis of them and the way they changed over time as groups came into contact with each other.
All in all, a thought provoking presentation that backs ideas up with concrete numbers.
After watching Dan Roam’s presentation, I decided to see what else looked good from Mix09. The day 1 keynote from Bill Buxton - available right now on the front page of the site gave me an insight into the mind of a designer that I didn’t have before.
Bill talks extensively about the history of industrial design and its rise during the great depression and that we can take the opportunities of the current financial crisis and use them to make usability design a priority.
I’m not sure if his logic, that crisis periods are inherently periods where design can prosper, is well founded but .. let’s hope it is. When you’re stuck in a financial hole, digging may not help but just sitting there doing nothing certainly won’t work. If innovative design and engineering can give us hope - let’s get to it.
Some of the ideas that Bill pushed strongly on were the notions that design has to be fast, has to be iterative and that only trying one approach to solving a problem leads to sub-optimal solutions. I’ve tried the first two of those ideas in development and they work like a charm. I wonder what it would be like to try to get several different solutions to the same problem in parallel? Perhaps that’s really what’s going on in the Java web framework world, or the .NET DI container world. Perhaps, rather than being frustrated by the problem of trying to learn and decide amongst multiple choices we should rejoice that we have options; we should be pleased that we get to choose the design that we believe in most.
The other big take-away that I got from Bill’s presentation was that in selling something you shouldn’t try to sell the item itself. You should sell the experience of using/owning the item. I can see this as a useful tool when trying to build software and also to make engineering decisions. Build software that will lead to a positive user experience and you’ll be a success. When considering two engineering alternatives, ask people to imagine the experience of living with that decision. Ask the technologist to put on his negative/remember-all-the-times-things-didn’t-work-the-way-they-should hat on and ask him to imagine what life would be like.
I’ve said it before, and I’l say it again. I love watching smart, passionate individuals talking passionately about their passions.
Mixing it up in Vegas: In this engrossing and entertaining presentation Dan Roam talks about his theories on sketches and how they unlock creativity and help communication and consensus gathering amongst groups.
I really enjoyed it, I’ll certainly try some of these ideas out, and I will probably buy the book. All those positives aside, three things do bother me about his presentation.
1. He starts off by saying that you don’t have to be able to draw at all to use his methods. That his ideas revolve around using simple shapes to communicate. Then he uses slide after slide filled with drawings that, whilst simple, are of a much higher standard than I could ever produce. (Yes I am that artistically challenged.) If simple diagrams are what you need to communicate .. why doesn’t he use any?
2. I’m willing to accept that using drawings as a means of communication engages parts of our brains that would otherwise lie dormant. What are the trade-offs? What are we sacrificing? Trading in my ability to logically critique something for my ability to create new ideas is something I’d want to do sometimes. When is it good, when is it not? Give me the down as well as the up.
3. I became suspicious when the Dan claimed that we can use pictures to solve any problem. That’s obviously nonsense. At best we might be able to describe any problem using pictures. Describing and solving are two different things. Don’t believe me? OK, well, all of my grandparents are dead. I love them, even those I never met. I’d like them back. Please provide me with the drawing that solves that problem.
Before I go any farther, I’d like to be clear that I’m a Black Pen Guy, When I talk, I like to stand in front of a white-board and scribble. I love to throw a marker to people and say, “show me what you mean”. Giving me a tool to make me better at design, communication and problem analysis is wonderful. That’s all you need to do to sell it to me.
Anyway, rants aside, this is a really interesting presentation with oodles of interesting ideas and anecdotes.
(Via Clarke Ching.)
I like the teams I run to use pair programming, because the end product is better. I’ve also heard lots of people say that they don’t want to do it.
I have a theory that pair programming is the brussels sprout of the technology world. Lots of people don’t eat them because, not because they think they’re bad for you, but just because they don’t like them
I have no children. When I do, they’ll eat brussels sprouts. I won’t do it because I want them to be sad, or to make those little sicky faces that children pull when they put something unfamiliar in their mouth. I’ll do it because I want them to be healthy, productive and to live a long time.
Here’s a rule of thumb I like to use.
Q. How do you know when a document is too long to be useful?
A. Print it out and try to slip it under the door of the person you wrote it for. If it doesn’t fit … it’s too big.
As a an addendum to my test; whilst you’re at the door, open it, go inside, and say hello. Nine times out of ten, that’ll do more good than the document.
I’m writing this post because a lot of my friends are dyed-in-the-wool Java and Ruby developers who believe that nothing good ever came out of Redmond. I’d like them to think again.
Over the last few weeks I’ve been listening to podcasts that have come out of the .NET community: Elegant Code’s Code Cast, Scott Hanselman’s Hanselminutes and Herding Code and overall my reaction has been, “Wow, the Microsoft/.NET community is really starting to get to grips with Lean and Agile”. This wasn’t the case the last time I worked intensively with .NET about three years ago, back then it seemed that MS and .NET developers were living in the dark ages.
Listening to people working from within Microsoft talking about using Scrum and XP and Lean and how it is making their development better is heart-warming to someone who’s been pushing this message for the last ten years.
That Microsoft are dogfooding their own applications, and changing them to make them work better in support of Agile methods is fantastic news. Microsoft can do a lot of good if they support these ideas openly, and that seems to be their intention.
Microsoft isn’t just making strides in the process department though, the advances they’ve made in the CLR and the languages that run on it are really starting to pay dividends. As this post from Matthew Podwysocki shows, the generative effects of advancing the language and the platform.
That the .NET platform has been pulling ahead of Java in the feature department for a while now hasn’t been a secret. But now, for the first time, I’m starting to see people using these features and talking about these features to solve significant problems rather than brandishing them as ‘the new hotness’.
If only it wasn’t tied to Windows, I’d buy some.
Bob Martin has a presentation he gave at a JAOO conference up on InfoQ. The title of the presentation is Craftsmanship and Ethics, which is somewhat misleading since the presentation is basically on Software Craftsmanship prefixed with “we should be craftsmen, craftsmen should have ethics, it’d be unethical not to”. I was a little disappointed by that - I was interested in his thoughts on ethics and how they relate to the development.
Overall it is an entertaining presentation that will leave the Agile and SC groups nodding and leave those with a different mind-set shaking their heads as normal. I enjoy watching passionate people talking passionately about their passions… so this was fun; but I don’t think it changed any minds or taught anybody anything they didn’t know.
I’m assuming that the crowd at a JAOO event is composed of experienced professionals who care about and investigate their industry. To effect change it isn’t enough to speak passionately. It isn’t enough to tell experienced professionals what you think or feel - they have their own thoughts and feelings and there’s no reason they should supplant their own with yours. People need compelling reasons to change, they need people to provide compelling solutions to immediate problems, they need to believe that by changing they are shedding risk rather than increasing their risk profile. Passion isn’t enough.
Uncle Bob, and the other leading figures in our profession have the opportunity to speak directly to thousands, indeed millions of developers each year, and I don’t think that what they’re doing is working. The Tony Robbins style pitch is enough to get people fired up at the conference, it doesn’t carry enough momentum to provide a solid take-home.
I’m reminded of Geoffrey Moore’s Crossing The Chasm: Agile, Lean, Craftsmanship, all these ideas have been sold to the innovators and perhaps even the early adopters, we need to cross the chasm to get to the next group of technologists - the early majority. Even this isn’t enough, though. We haven’t got the message through to project mangers, business analysts or customers, let alone C*O types. We can present compelling cases when we talk to people one-to-one, but the ideas haven’t taken root in these communities; in Chasm terms we still don’t have a hook in the innovators there.
If we advanced the management and technology communities in parallel we’d have a much better chance of improving the way software development is done.
How do we do it? Well, first off, I think we need to stop talking about quality, top talking about Agile and Lean and Craftsmanship and start talking about value. Value is what everyone wants. Developers want to create value, managers want value created, customers want to buy valuable software.
I firmly believe quality leads to value, but telling people they should want quality leads nowhere. Tell someone they want value and they retort, “Of course I do, how do I get it?”. NOW you can say, “Well, every industry in the world has come to accept that building in quality leads to higher value.” At this point, I’ve never heard anyone say, “Hmm, that sounds hokey. Go build me some shit. I’m sure that my best path to value is by heading through latrine-town.”
When technologists, managers and customers talk about value, they may not all understand it in the same terms. At least not at first. But until they agree on what value is, there’s no way to build successful products or relationships.
The idea that people might not have the same understanding of value is something that many technologists don’t get right off the bat. To explain it, I need to take back something I said a few lines ago. I don’t believe that quality always leads to value. This also brings me back to Uncle Bob’s talk.
I have worked in environments where financial opportunities would arise out of nowhere, last for a few days or a couple of weeks and disappear. In these cases, the opportunity to make millions of dollars a day can exist if you can(in abstract terms) get information in, process it and send it back out within a specified time period. Oh, and the countdown on how long you can do this for has already started. Every moment between now and shipping costs a non-trivial sum of money. In these cases, value comes from shipping. The software might have problems - if it crashes every fifteen minutes night and day, that’s OK .. we’ll run ten copies on ten machines and have ten interns sit and watch them clicking the icon every time it falls over. The software doesn’t have passwords or security, that’s OK we can hire a rent-a-cop with a gun to keep people away from the computers.
Overall, doing this makes money. Sure, over the first few days the team try to improve the quality so that half the interns can go home - but the software is going in the bin in a week .. improvements beyond basic stability are a drain on assets nothing more.
I’ve heard developers shout about this being a terrible, shoddy way to do software and insult the developers who build it. I may even have been one of them. That’s because I wasn’t thinking about generating value with my software, I was only thinking about software for the sake of software.
Now I think about value, I can understand why people build software like that. I can also understand that we can get that software out of the door faster by looking at what we build in each case and trying to pull together some pieces that they can glue together the next time an opportunity arises. Pieces that’ll let us be EVEN faster to market next time. That’s value.
My point, value isn’t a universal truth. Value is relative to the situation. If everyone talks about value at the start, and forms a common understanding we can fit everything else into the framework this gives us.
Uncle Bob, luminaries of the development world, talk about value. Please.
This morning I opened up a copy of Dave Hitz ‘How To Castrate A Bull’ and I’ve been totally blown away. I read it cover-to-cover without standing up. This was unfortunate because I was in the bath. I filled the tub over and over with hot water until I was done because I couldn’t bear to stop to dry myself until I had got to the end.
Dave (someone else I’m on first name terms with by dint of having read his writings) tells of his experiences as a founder of NetApp. The book is filled with amusing stories and side-bars, coupled with sage and hard-won advice, recounting of failures and successes with equal honesty, passing on of lessons learned from others and a thousand tiny observations each a gem in of itself.
I only wish Dave had a second, parallel company at the same time so he’d have a sequel.
Last week I said that I’m using the time I have free to catch up on my reading - getting to all those books I’ve been meaning to get through.
First on my list was Eli Goldratt’s latest book The Choice. It’d been a while since I read his other works, so I decided to re-read them first. In the last few days I’ve re-read The Goal, Necessary But Not Sufficient, Critical Chain and It’s Not Luck. Every time I read these books, I get something new out of them. If you’ve not read Goldratt’s work, I heartily recommend it.
I said that I was re-reading Goldratt’s earlier works in preparation for reading his latest book. I haven’t got to that yet, that’s next on my list. I got distracted when a friend tried to explain something to me by referencing Seth Godin’s Purple Cow theory and, since I haven’t read the book, I didn’t know what he was talking about. So I read ordered a copy from Amazon and read that last-night and this morning.
This is the first book I’ve read that just focusses on the ‘getting the message out’ end of marketing. I’m surprised that I got as much out of it as I did. In retrospect, this is a field I should have spent more time reading about. I need to work to fill in my knowledge here. Anyone with pointers towards the ‘right’ reading material feel free to drop me a line.
Agile development is more culture than process: “Why thinking of agile as culture and not just process explains resistance and difficulty in teaching and learning the approach”
(Via Jeff Patton.)
Jeff Patton presents a well thought out, well articulated article. But one I couldn’t disagree with more.
Jeff presents an argument that Agile isn’t a process, but a culture, and I’d agree that Agile isn’t a process but, despite the many Agile proponents who make it seem that way, Agile isn’t a culture either. Agility is just one quality that an organisation can have. An organisation can have an Agile culture, but that doesn’t mean that that their culture is Agility.
Presenting Agile as a culture is something I’ve seen many times, and it puts more people off. Agile zealots, a club I was a member of a decade ago, try to sell Agile as a culture in a way that reminds me of Mao and his Cultural Revolution; they want to come in to your organisation, declare your culture to be bankrupt and rip it out, replacing it with an idealised regime of their own. (I do not put Jeff Patton in this category, his writing is very sensitive to the existing culture of organisations.) Mao famously said that political change can only come through the barrel of a gun. Mao’s way may have changed china. But it isn’t the way to change organisations in the twenty-first century.
An organisation that wants to undergo an Agile transition is an organisation that wants to acquire a new quality. Adopting this new quality is not easy, that’s why experienced Agile practitioners can be invaluable during this process. Cultural change is not easy, it is painful for organisations and the people that make them up. I think this is why Jeff, and the rest of us who’ve been down this road, have seen push-back and pain when performing transitions.
You must be sensitive to the needs and feelings of an organisation. You must be conscious of the times when existing cultural practices, processes and artifacts are in conflict with the changes you are trying to make. You can’t steam-roll people and tell them that their existing culture is valueless, you have to show them what they have, where they can be and help them make the journey.
After the transition an organisation should have Agile qualities. They shouldn’t be Agile. An organisation that has no quality but Agility can not survive, they have nothing unique to offer the world. As someone performing an agile transition, we should strive to ensure that the organisations we work with should be strong, energetic, diverse, healthy and Agile. They should have their own culture at the end of the process, just as they did at the start. Just a bit better.
Over the last few years, I’ve moved past Agile. Not that I think it is bad, I still embrace it fully, and I still use Agile practices because I believe they work. But Agile isn’t everything, any more. It never was, I just didn’t see all the other things that I and those around me were doing. I think that Agile brought the humanity back to software development, something that had been bleeding out and something that we need to be effective. Agility recognises that it is people who write software and that by remembering that fact, we get the most out of the people.
These days I consider myself to be in favour of Humane Development. Respect people, respect their culture, challenge people to do more, to do better, reward them for successes, help them when they falter, teach them to be the best they can be and expect their best efforts from them in return. Like Agility, organisations need to have Humane as a characteristic if they are to thrive.
I switched from Safari to Firefox about six months ago. Firefox had a feature that made me want to switch; if you close Firefox with open tabs, it offers to save them for you for next time. At the time I was taking my laptop with me to work each day and shutting it down during transit saved battery power. It was a pain to have to go through all the tabs and figure out what to bookmark and what to discard.
So that seemed like a good idea, and I’ve used that feature every day. I now have over one hundred tabs open, many of which I’ve not looked at in months. In fact, this article Ancient Egyptian Numbers is one I opened when Clarke linked to it in mid-october. I’ve not read it. I still plan to but …
The feature I liked so much, turns out to be an anti-feature; at least in the hands of a someone with a tendency towards procrastination, like me.
Who’s Your Coding Buddy?: “I am continually amazed how much better my code becomes after I’ve had a peer look at it. I don’t mean a formal review in a meeting room, or making my code open to anonymous public scrutiny on the internet, or some kind of onerous pair programming regime. Just one brief attempt at explaining and showing my code to a fellow programmer — that’s usually all it takes.”
(Via Jeff Atwood’s Coding Horror.)
Jeff Atwood makes me laugh. He makes a valid point - he finds having someone else look at his code valuable, he feels it makes his code better. Something I think we’d all agree is true. He even pulls out statistical evidence for the efficacy of code reviews, which would add support to a well reasoned argument.
Of course, Jeff can’t leave it there, he has to back-track on his own point. Code reviews make your code better but heaven forbid the idea that a group of technologists should agree to do something that makes your code better. He rails against formal reviews and pair programming, instead he suggests ‘just have a buddy look at it’.
I really don’t understand the man, what grudge does he have against the idea, that people can agree to do things that make sense? And beyond that, if people can’t agree to do the right thing, shouldn’t their manager insist? I can’t think of any other industry where leading members of the community would speak out in favour of people NOT doing the things THEY think are right? Would Jeff approve of the idea of a leading surgeon calling for his comrades to give up on M&M reviews and just ask a buddy why their patient died?
Recent Comments