April 24, 2015

Thinking About #NoEstimates?

By Johanna Rothman

I have a new article up on agileconnection.com called The Case for #NoEstimates.

The idea is to produce value instead of spending time estimating. We have a vigorous “debate” going on in the comments. I have client work today, so I will be slow to answer comments. I will answer as soon as I have time to compose thoughtful replies!

This column is the follow-on to How Do Your Estimates Provide Value?

If you would like to learn to estimate better or recover from “incorrect” estimates (an oxymoron if I ever heard one), see Predicting the Unpredictable. (All estimates are guesses. If they are ever correct, it’s because we got lucky.)

April 24, 2015 11:32 AM

April 21, 2015

Thinking About Estimation

By Johanna Rothman

I have an article up on agileconnection.com. It’s called How Do Your Estimates Provide Value?

I’ve said before that We Need Planning; Do We Need Estimation? Sometimes we need estimates. Sometimes we don’t. That’s why I wrote Predicting the Unpredictable: Pragmatic Approaches for Estimating Cost or Schedule.

I’m not judging your estimates. I want you to consider how you use estimates.

BTW, if you have an article you would like to write for agileconnection.com, email it to me. I would love to provide you a place for your agile writing.

April 21, 2015 02:06 PM

April 19, 2015

Broadening Developer Horizons

By Rachel Davies

XP is an approach that helps us to deliver valuable software iteratively, to apply it we need to setup our teams to make releasing change to customers as easy as possible. We avoid waiting around for individual team members to make changes, by applying classic XP practices -- Collective Code Ownership and Pair Programming. Each pair of developers is free to change any code that they need to without anyone vetting their changes, they ensure that all tests pass and keep code relatively clean by refactoring as they go. We share knowledge across the team by rotating pairs daily. If a pair runs into difficult decisions regarding design choices, they can call for a huddle with their team mates, sitting together in an open workspace means that's quick to do. This XP way of developing code is liberating as we can easily make changes in the right place rather than working around organisational barriers. It can be also be humbling, as our code is often improved by other developers as they pass through.

To work this way, we find it helps to build teams of extremely capable developers who can work on any area of the codebase rather than hiring a mix of frontend/backend/DBA specialists. Developers who only know enough to work in a single layer of the codebase limit who's available to pair on the piece of work which is most valuable to pick up next. At Unruly, we only hire “full-stack” developers, this gives us confidence that any pair of developers can work on any area of the codebase (within the products that their team is responsible for) without experiencing hand-offs and delays waiting for developers with a different skill set. It also helps avoid some of the friction that can spark due to single-layer thinking.


To make collective code ownership easier, some product teams select a homogeneous stack such as Clojure with ClojureScript or JavaScript all the way down using Node. At Unruly, our developers need to be fluent in JavaScript and Java with a smattering of Scala. Full-stack developers are bright people who can keep pace with developments in multiple languages and frameworks rather than immersing themselves in a single core development language. Being a full-stack developer is more than being able to write code in different languages, you have to understand idioms and patterns for UI, middleware, database realms too.

Being a full-stack developer is also much more than becoming a polyglot programmer. Laurence Gellert’s explains in his blog that there’s a greater breadth of skills that a “full-stack” developer needs. You’ll need to appreciate the environment that your live system runs within and have the technical chops to be at home with making environment changes. You'll also need to broaden your horizons beyond thinking about code and get to grips with developing a fuller understanding of the business you work in! Michael Feathers recently gave a talk in London where he used the term “Full Spectrum Developer” which neatly captures the idea that there's much more than being able to work across different software layers in a given architecture.


As the software craftsmanship movement has brought to the fore, serious developers need to take personal responsibility for improving their skills. Of course, becoming a full-stack developer is mUsing-laptop-on-snowy-mountainore than reading the odd business book in your spare time and writing toy programs in obscure languages when you get home from a long day at work. You can also get together with likeminded developers on a regular basis to hone your skills through Code & Coffee sessions outside work and work on pet projects like building games and mobile apps at home. But in my opinion, this only scratches the surface - you will only get to grips with being a full-spectrum developer by working in an environment that allows you to get your hands dirty across the full stack and interact directly with users and stakeholders. Typically these are startups or small companies that practice agile software development. If you take a look at our current open roles, you’ll see they’re much broader that you’d typically find in a large corporation.

As an agile coach working with product development teams at Unruly, my focus is on how we can support developers to expand their horizons, to gain a better understanding of our business and how they can help figure out the most valuable software to deliver iteratively. Our developers take responsibility for researching different strands of product development and identify the most valuable ideas to take through to implementation (I'll write-up more about how we do this in another post soon).

We also recognise that build learning time into our work week is essential for developers to stay abreast of new tools and frameworks. All of our developers get one day per week to dabble and learn new technologies — see my previous post about Gold Cards. We recognise that industry conferences can be places where you hear about new trends so developers get three days and an annual allowance to spend on attending any conference they feel is relevant to the personal development at work. Our developers also take turns running weekly coding dojos (during work time not through their lunch) to get hands-on practice time with new languages such as Go, Scala, Rust and mobile phone application development. Developers get the opportunity to share what they learned to other teams through lightning talks and this gives them practice in presenting too. All of these things are ways that organizations can support developers in broadening their horizons while at work rather than eating into their early mornings and evenings.

There are a few things for developers to weigh up when considering whether to specialise deeply or broaden their horizons. What do you sacrifice when following one path versus rewards to be gained? The main reward for full-spectrum developers is building greater confidence to dive into different technologies; you may spend less time writing code but become more able to deliver end-to-end solutions that hit the spot. As generalists, you likely have a wider choice of companies to work at and are more resilient to industry trends. As specialists, you gain the pleasure of total immersion in a particular sphere of software while you build tolerance to the frustrations of waiting around for others to do their bit. It's up to you!

April 19, 2015 06:31 PM

Workplace Design: Creating a Home from Home

By Rachel Davies

LolaLast week one of our stakeholders brought his pug dog, Lola, along to our product review meeting. “Watch out, she likes feet!” he joked but she remained quiet and well behaved throughout the meeting. Unruly is not the only place I’ve come across where dogs have been accommodated at work, another had a dog basket in their main board room. I appreciate not everyone likes dogs around but I like working for a company that’s not too stuffy to allow people flexibility to make our workplace more homely.

We’re lucky at Unruly to have a dedicated People & Places team who work closely with our Design team create a work environment that has personal touches. There are many informal meeting places around the building to make collaboration easy and it’s decorated with original artwork GoldFramePortalreflecting our culture. Little things amaze visitors as we show them around, for instance we created a two-way webcam portal between our London and New York office with a gold antique-style frame, which makes it seem more special and echoes Harry Potter where characters move around. What’s the business case? Creating an environment that allows human expression encourages creativity to flourish in our work.

The design of our workspace is not owned by a central team outside development. We recently reorganised our desks and unlike many companies, where a "Desk Move" is a dreaded logistical nightmare involving packing things up for another team to execute overnight, our developers simply got stuck into disassembling desks and lifting floor tiles themselves to get everything in the right place. Our spirit of collective ownership and taking responsibility for how our code structured seems to extend out to our surroundings. Taking care of our workspace, isn’t somebody else’s job. DeskMove

Our teams use our walls and whiteboards for practical purposes but with a sense of humour too. Even electronic tools get a bit of customisation, we use Trello for our backlogs and teams can add distinctive backgrounds to make them easier to pick out.

Teams in bigger companies often find that their boards are the easiest areas to start personalising, when you introduce Kanban boards you can involve everyone on the team in designing the layout. Rather than diving straight in to moving things around, you can create a mini-version of the new layout with sticky notes. I think it’s important to give everyone on the team the opportunity to mull the proposed design over and allow time for tweaks. We’ve taken this approach with how we lay out our boards and our desks (as in the examples below).

Desklayout
BoardLayoutI appreciate that many people work in organisations that don’t actively support personalisation of the workspace but you can start small with a potted plant, a team mascot, a little whiteboard artwork. You'll likely find personal touches are noticed and soon start to spread around surrounding teams. Another small step that you can take is to adopt iteration names or pictures that pick up on what’s going on in the outside world or reflect metaphorically on current mood within the team. In software development, we spend a lot of time in an office environment, taking care of your surroundings helps to take care of the people working within them.

April 19, 2015 06:28 PM