Ok, this sentence sounds like a fortune cookie. Maybe I’m turning buddhist, but I love it. And it applies especially well to software development. As a craft based on human interactions, software development is a set of compromises. There’s no such thing as a best practise, a definitive process, or a methodology that works for all contexts. I don’t even understand how words like agile and process or methodology can have ever been put together in any mind.
Agile and lean are approaches that work the best according to what we know today. But they are just containers of values and practises that constantly evolve. They don’t tell you what words to use in discussions, or what lines of code to write for every single situation. They need to be adapted to every context. Scrum and lean startup by the book might be good enough to design a simple shopping cart, but not necessarily to design a car, a distributed NoSQL database, or a nuclear plant software complying with all required regulations.
You always need more than what you can learn in trainings or books. Your situation is always unique and new. If it’s not new, why bother doing it? If you didn’t need to adapt the framework, why would scrum define the basic team around the opposite powers of dev, backlog, and test? Why would lean be based on kaizen in the first place? A set of definitive rules, a process, would be enough.
In the end, you always need to adapt the way you build, collaborate, understand each other, find solutions, analyze gaps, code… and to get better at it. Always. There’s no end to getting better. Because you can always be better, and because the context keeps evolving. And that’s what I love about it. You always can and must do better. Everytime you’re not trying to get better, you’re getting a bit closer to the death of your team, project, organization, company. The world won’t wait for you.
So perfection is the goal, but you can never reach it. How exciting! That’s what the best approaches known so far explain to us right from the beginning. You need to find the right compromise, for every situation: test coverage vs test campaign maintainability, code performance vs readability, taking the time to discuss and understand each other vs saving meetings, writing just enough documentation vs focusing on working software, self-organizing teams vs facilitating their progress, releasing features vs stabilizing the product… There are hundreds of parameters you need to balance. And you always need to tweak the buttons as the situation evolves.
In the next posts, I’ll try to talk a bit more about the tradeoffs we are faced with day by day. What the books don’t say, and the concrete problems they don’t give solutions to. I’ll try to describe the approach we’re taking to oil the wheels. I hope it will save me the shrink.
We just had a very interesting discussion about estimates. We started this discussion with re-assessing the weight of our story points, but it lead us to talking about why we need estimates.
I think the ideal goal of any framework or methodology, as for managers, is to disappear and lead to anarchy (but not chaos). Therefore, I look for any occasion to get rid of iterations, estimates, follow-up, or any other method or tool. I’d like to get to a minimum process focusing on communication, and then make it disappear as it becomes natural.
Estimates can be useful, but they are expensive. And we weren’t clear about where they were useful. So we tried to think out of the box, and rebooted our thinking about the reasons why we needed estimates.
In a recent post about transitioning to agile, Dean Stevens said:
[We can] explain some benefits of an Agile Transformation this way:
- Business wants predictable and improved throughput.
- Customers want quick lead times for quality product.
- Teams want a good working environment where they can contribute and succeed.
I thought the ultimate goal of estimating was to come up with a long term planning (few months) with some confidence. From my experience, customers demand some planning for their requirements.
But I was explained that getting to that end to sell something was a commercial failure. Long term planning is never reliable. It is not when it comes from the provider, and it is not when it comes from the customer! I know you rarely deliver exactly what you planned a few months ago. And does your customer still exactly needs what he requested 6 months ago? Is he still ready to use it now that you’re delivering him?
Negotiating such plannings in a precise way is a poker game, where everybody looses.
You can still have a high level long term planning, but be clear on the fact that it is nothing more than an unclear wish-list based on the knowledge you have today. Don’t constrain your development process for this objective. Manage long-term planning outside of the development process, using tools like portfolio management or epic/theme backlog, where you estimate your epic/themes in comparison with other [done] epic/themes, and not development items like user stories.
The agile community agrees on the use of the discussion around estimates. I totally agree with it. Estimating is a great way to make sure we have a discussion. It’s a great way to detect comprehension gaps between team members (devs, qa, business,…). It also allows devs to agree on smaller chunks of the story (tasks) to run in parallel in order to swarm. By having this discussion, and the objective of a consensus around estimates, we have a better chance to align our comprehension of the why, the what, and the how.
But estimating is only one way to get there. We could get to the same point with a different objective, like colorful or timely drawings, a list or a number of tests, mock-ups,… So again, if the goal of the estimate is only the discussion, if it’s a game among others to run during the iteration planning, we should not make the rest of the process heavier for it.
What about the process? Through estimates, you get a throughput. By making this throughput predictable, you make the process and the backlog predictable. By optimizing your throughput, you optimize your whole process. By detecting deviations in the throughput, you detect exceptions to your standard process (i.e. deviant deviations), and thus optimize it. And so on…
But there are other ways, like following up the cycle time, the WIP, and thus bottlenecks. You can monitor your throughput as a number of items, and not a number or story points. If your items are within a reasonable size, the standard deviation of your throughput and cycle time should be acceptable (compared to estimating error or your constraints). Agreeing whether an item is of a “reasonable size” is estimating. But I believe it is a lot lighter than formal methods like planning poker.
It leaves us to the short-term planning. Estimates are useful to know what you’ll do in the next few weeks. Like for long-term planning, I’m not clear on the goal of this. Making sure you respect due dates is definitely a fair objective. Motivating teams with an objective to reach is another one. Prioritizing considering constraints and slack is also important. Having a prioritized backlog where teams can pull work without bothering a PO is great. Fine, we’ll suppose you need to know what you’ll be able to produce in the next few weeks. And drum roll…
BUT is estimating useful to have a prioritized development backlog and a short-term planning? It is if your throughput and cycle time standard deviations are too important. If they are, you need to sort your items by categories where these standard deviations are acceptable.
As a conclusion, what you need is buckets where cycle time and bandwidth occupation are close enough for all items. If you only have one bucket, it’s perfect. If you have more than 4 or 5 buckets, you should really think about it. Estimating is knowing which bucket fits your item, or splitting an item so that all sub-items can fit one of your buckets.
For different levels of plannings, you can have different buckets. For example, you may have development buckets for the development backlog, and release buckets for the long-term backlog. Those buckets are not of the same nature. Neither are the items they contain. Don’t try to fit development items in long-term backlogs, or long-term items (epics/themes) in the development backlog, without further analysis.
As a conclusion conclusion, monitor your throughput, your cycle times, and their standard deviations, identify your buckets, and make them the least possible.
What do you think?
Lately another team organized a coding dojo. The feedback was great.
The idea of a dojo is quite simple. You set an objective for about 1h of dev (games are cool). You begin with a pair of developers. All others must be able to see them and what they do (e.g. using a projector). Developers are asked to say what they’re doing, and apply pratices like TDD. The navigator should also do his job, of course. Every 5 minuts approximately, the pair changes: the pilot leaves, the navigator becomes pilot, and someone else comes in as the navigator.
Just looks like a game, right? But it is helpful for many aspects, not only for technical stuff. In this team particularly, most of the devs attending the dojos were not very experienced in software engineering and agile. Of course, they learned technical things from their peers, like:
- IDE features and shortcuts
- coding technics
- refactoring technics
As everybody could experiment these in a safe environment and witness their benefits, it was also a great way to foster XP practices like:
- pair programming
- unit test first
- always refactor
And last but not least, most feedbacks were, quite surprizingly, also about observing how the team interacted:
- what devs knew or not
- how they analyzed problems or found solutions
- how they interacted with their pilot/co-pilot
I was surprized about the outcome of this experiment… not because it didn’t meet my expectations, but because it went way further.
Thinking about it, the coding dojo is close to the optimal compromise between safety and realism for software engineering. You can try new things, observe their benefits, observe your teammates. You can do it without bad consequences but with hands on, in a very short but effective time. I will definitely use it for passing dev messages.
Has anyone tried coding dojo before? Do you have any feedback about it?