Hiccupps

I watched Allan Kelly 's Reawakening Agile with OKRs presentation at the Cambridge Agile Exchange last night. You can find a lengthy summary in his recent article for InfoQ and there's a book too, but here's a few points that caught my attention. If you've been around the block you'll have doubtless come across OKRs — objectives and key results — and perhaps cynically think of them as the antithesis of agile working, a management tool for the top-down imposition of overcommitments. From that perspective, promoting OKRs as a way to save agile could look a bit like the kind of sharp tactics that unscrupulous second-hand car salesmen might employ: "OKRs, one careful owner, a nice little runner, thousands of miles left in this one." Fortunately, Allan is open about the history and specific about the contexts in which he thinks OKRs can add something. In his view, their backstory is why OKRs are also a useful hack for the kind of "mil...

Tonight I watched Fundamental Principles of Organisational Design with Doug Talbot , hosted by Cambridge Agile Exchange .  Doug has built a model of organisational design which he uses to assess status, identify targets for change, prioritise changes, and design interventions intended to achieve them. The model is based heavily on experimentation, deep reading, and hard-won experience in the broad area of software development practices, projects, and companies. The model identifies nine areas of importance using a matrix of three columns concerned with creation (teams and structures, building the right thing, building the thing right) and three rows concerned with company behaviours (leadership and principles, policies and tools, day-to-day practices). In some sense this is a meta model onto which others can be mapped. For instance, Scrum is located in the lower middle-right (building/practices) while sales incentive programs are middle left  (teams/policies). Doug notes tha...

It's nothing personal I'm sure but at this week's Cambridge Agile Exchange Ben Mancini told me that I'm a failure. Ouch! Failure, he says, is "the state or condition of not meeting a desirable or intended objective ... may be viewed as the opposite of success" and his hypothesis is that failure provides more learning than success but that we talk more about success than failure. In his talk, Ben showed examples of people who have succeeded despite repeated failure, talked about the negative effects of failure, ways to reframe perceived failure, and the benefits of pushing through failure's cloud to its silver lining. Along the way he shared some of his own failures and invited us to share personal faux pas with our neighbours in the audience then look for the learnings in them. One of the reasons I attend meetups is to be provoked into thought so, in no particular order ... In my time I've certainly done things that I'd have preferred ...

For my lightning talk at Cambridge Agile Exchange last night I tried to persuade the audience that, even in today's agile world of self-organising teams and coaches, value can still be found in the traditional management literature. I talked about three books which unashamedly acknowledge that everything revolves around people: Managing Humans by Michael Lopp Behind Closed Doors by Johanna Rothman and Esther Derby Managing Yourself and Others by Gerald M. Weinberg That's right. Everything. People. Literally. Everything. Is. People. In ten minutes I couldn't do more than pull out a handful of key messages and these are the ones I chose: Do be congruent. Do be open. Don't be a prick. They seemed to like it. Particularly the last one. Here's the slides: I also wrote notes on the other talks . Image: Cambridge Agile Exchange

I gave one of six lightning talks at Cambridge Agile Exchange last night. Here's a quick summary of the others and, up top, my sketchnotes. Brian Beckett spoke about three major problems of engineering management: goal-setting for individuals, metrics for teams, and people . People are worst, he said, but also people are the best, and in fact are the only thing. For Brian, software development is an art and its practitioners will artfully game quantification, so engineering managers must be art critics, and favour qualitative assessments. Dani Oliver described how following his passion for agile approaches has led him from development through Scrum Mastery and into a role as a Release Train Engineer in the SAFe framework. And what is an RTE? He gave us his take on it: the keeper of (weird) practices, a breaker of the status quo, an uber Scrum Master, someone who cares. Mariapaola Sorrentino described joining a Scrum team where commitment was low relative to delivery (in ...

Pete Douglass and Karl Chambers are Scrum Masters and recently found themselves dissatisfied by projects that they'd worked hard on but were (a) taking a long time to get anywhere close to deployment, (b) being delayed by late-breaking feature requests, (c) both of the first two, and (d) not fazing the business at all. As they saw it, the business likes to see its people getting on and doing stuff. If using Scrum, the business typically likes to see a consistent or upward-trending velocity for its teams: more work being done. The business will often not differentiate between between a simple proxy metric and the thing they'd really like to measure, between work done and value delivered, between outputs and outcomes . In their talk at  last night's Cambridge Agile Exchange  Pete and Karl described a couple of ways they tried to help the business side to see that having busy development staff wasn't the same, or even directly related to, the delivery of business v...

  We play tricks on ourselves, Woody Zuill says. We think that we estimate because it gives us control. In reality, we estimate because we fear losing control. The irony, of course, is that we aren't in control : estimates are inaccurate, decisions are still based on them, commitments are also based on them, projects overrun, commitments are broken, costs spiral, ... Spending more time estimating typically doesn't make us better at estimating but it does take time away from doing.  Zuill's experience is that it's possible to build software without any estimates by taking an important piece of functionality, building only the absolutely critical pieces of it, and then putting it in front of someone. The doing, and the review of what's been done, will help to determine what should be done next. Sounds simple? Yes, but it's not easy . It's crucial to find allies and customers who are ready to accept it. Here's my tidied-up sketch...

I was at Cambridge Agile Exchange 's first Unconference the other night and I pitched a 15-minute discussion with the title  The value of testing is ... : I'm a tester and I'm interested in the value that others perceive testing brings to product development in their contexts. Where does testing add value? Where does it add most value? When does it add value? What kinds of testing activities deliver the right kind of value at the right kinds of costs? Do you need testers in order to test?  The participants in the session included product owners, scrum masters, developers, coaches, an ex-test manager, and a colleague from Linguamatics who has just switched to testing from linguistics. (And I'm still hiring .) The mission I had in mind was to gather data, to solicit and record views, and to not push some kind of militant testing agenda. I think that worked well, and if I had to pull one observation out it'd be how quickly the conversation turned to  th...