César has been a good friend and a great mentor for me. He is resourceful, dynamic and energetic. As it happens he has also contributed ideas and comments to this blog.
If you do have a vote in the 2009 Agile Alliance board election, please take a moment to review César’s position statement and then vote, for him preferably !
Last week the Bay APLN had a great meeting where Chris Sims offered some of his agile learning games. The games offered the opportunity to feel and illustrate what has long been published (and is still thoroughly ignored by a large chunk of managers and workers). The first game we played was to illustrate the effects of multitasking. I have come to realise two things at the end of the game.
First what we call multitasking really is an interruption driven work process. That process is a consequence of our overall work organisation. Instead of having cadence, we usually expedite. THe way we expedite is also grounded in the idea that we should not be idle and we should be “utilised’ all the time.
Second the downside of multitasking really is the time it takes to resume a task after an interruption. It is a set up time or a transaction cost.
A couple of things were illustrated. I offered that the pomodoro technique was a great help to handle multitasking. Essentially the pomodoro technique provides cadence and thereby suppresses the interruption driven work style. In exchange it provides predictable windows to address urgent requests. In this way it forces triage between urgent and not urgent while preserving the ability to adapt the work stream. It also enforces the idea that it is good to have idle time. Other signalling techniques were offered to prevent interruptions.
It was interesting to witness that the default attitude we had to resolve the problem of interruptions was to increase the batch sizes to avoid them. Essentially the same idea as reducing the set-up time in the industry. Importantly the discussion turned to techniques to reduce the transaction cost (context switching time) associated to multiple tasks. This is the realm of getting things done techniques (to-do lists to boot). One interesting remark from David Chilcott is to note down the next step in your current task before switching to another task.
To summarise, multitasking is good. Interruption is evil.
What techniques do you use to cope with interruptions ? What do you do to facilitate context switching ?
Today I am starting a new job. Different company, different title, similar role. So I thought I would try to describe why I am moving on.
I am going back to a software vendor I left it a few years ago. I left because I was missing direct contact with the business users. I left because I felt I had reached the limits of my influence and growth there. I am going back because I am given a great opportunity both in terms of career and personal development. I have a chance to further the changes I helped introduce back then. I get a chance to apply innovative solutions. That is the bottom line for me. In my previous role, despite all the great people I met and worked with I was not getting to apply innovative solutions. And therefore I was not learning as much as I would have liked. This is the deep reason why I felt dissatisfied. The other elements that took part in my decision were only the back breaking straws.
In fact I strongly believe turnover is beneficial for companies and employees alike in the software engineering world. As long as the turnover aligns with project duration it is not overly destabilising. The company gets to hire new people with fresh ideas. The employee gets to learn new things. I wonder if knowledge workers could be classified in the same way as open space participants: pigs, bees and butterflies.
What do you think ? What kind of worker are you ?
The Bay APLN was kind enough to enable its members to beta test the Group Coherence workshop that will be presented at Agile 2009 by César Idrovo and Joanna Zweig. And it was really good. I would not go as far as life changing (as others have reported) but it certainly helped make sense of what lies beyond team dynamics.
I will avoid spoiling the experience of future attendees by describing the workshop. The process and the tools you will be building through the workshop will help you facilitate the apparition of group coherence. And it is far from being an exact science for now.
My personal highlights were:
This eventually led me to form the metaphor that group coherence is a crystallisation process. The chemicals (people) are at some temperature (group dynamics) and under some level of pressure (deliverable, urgency, social pressure). When temperature and pressure align (and unfortunately that alignment depends on the chemicals) a crystal is formed. It could be a snow flake or a diamond.
Now some may prefer the cuisine metaphor but in the end, it is all chemistry anyway.
This is a rebound from the openspace session I hosted at the BayAPLN event on April 21 2009.
III started by noting that it is not your money. I initially interpreted to mean that therefore we do not have to care. Except if you have been entrusted to manage it and you have a fiduciary duty to make the most of it. Which lead us to the two main themes that informed the question which we essentially held to be the two sources of technical debt. One was the managerial impact. The other is the professional integrity of the team.
Lack of planing, disregard for appropriate buffering on delivery dates, inability to motivate the development team are all very heavy contributors to the increase of technical debt. The primary reason is that they tend to strip the development team members of their professional integrity, part of which is the pride people put in a work well done. In essence those managerial attitudes are akin to asking team members to break the windows of the building they are making. Or to cut on the cost of material while building in a seismic zone. To that extend technical debt resembles more a ponzi scheme than an actual financial debt.
We found hope in the professional integrity of the team. This professional integrity means, in my mind, that a developer should leave the code in a better shape than he found it. Pushing further in that direction it means that repaying the technical debt is a deliberate opportunistic activity. In other words technical debt should not be repaid for the sake of it, but only when it causes friction in the current work. Its repayment becomes continuous and integrated in the work stream. However, a lack of professional integrity (whatever the reason) will let entropy creep into the system and burden it with technical debt.
The conclusion, for me is three folds. First I changed my definition of technical debt to “things that could be done better” (now not, not things we could have done better). Second, you should not have to care about technical debt. If you have to reserve time to address, something is broken and should be fixed first. Third some debt is good and even inevitable, don’t try to eliminate it for the sake of it.
The BayAPLN was organising an open space event on the theme “Spring Cleaning…”
I was a bit disappointed that my proposed session “Is Technical Debt the Dark Matter of Software ?” did not get any interest. My second entry “Why should we care ?” was luckier as it attracted III and Paul Beusterien and lead to a very interesting conversation summarised in the proceedings along with the other sessions.
I also thank Chris Sims for picking my badge at the raffle. The ThoughtWorks Anthology: Essays on Software Technology and Innovation (Pragmatic Programmers)
I was troubled a few days ago when I heard a development manager talking about strategic initiatives and “tactical” solutions. I felt very strongly that the implied meaning was low cost, low quality solutions.
I am very grateful to Tim over at thedwick for writing that we should essentially reconsider that implied meaning. I would go even further, every single solution implemented by a development team is tactical in nature. Tactical does not so much refer to scope or quality as it does to the amount of control one has on the outcome and the time scale.
Strategic is when you have some level of influence on the goals and outcome but no real control. Tactical is that you may have some influence on the goals and full control on the outcome through your actions (your actions therefore have to adapt to local conditions and oppositions and overcome them). A strategy usually results in plenty of tactical decisions and actions that do not need to be fully defined in the plan.
The second aspect of the difference between strategic and tactical is the time scale. Strategic plans are liable to change as the environment changes until the strategic goals are achieved. The strategy will also change based on the tactical situations reported. Some goals may be modified or even abandoned if it appears they have become too expensive to achieve. On the tactical side, the goal is usually firmly defined and achievable in a relatively short time frame (a few hours to a few days) which leaves little room for changes.
One corollary of these two aspects is that when a tactical goal is achieved there is no reason to come back to it to achieve it again but better. To use a military analogy, let us imagine that the goal is to take a house in a city. The unit blows a couple of houses around to remove resistance and then storms the objective. Three weeks later, after the city officials complained, the unit is asked to rebuild the two houses and asked to put back the opponents that were in them and then take the same house again without destroying any other buildings in the city. That is exactly what is usually implied when a development manager talks about a tactical solution.
PS: It will be obvious that, in the analogy, the tactical goal has actually changed but let’s keep it simple.
Not so long ago I realised how many of the agile characterisations done by opposing Agile and Waterfall do not apply in my experience. In other words I have never encountered a waterfall development management process. What I have seen is plenty of ad-hoc processes derived from the vague knowledge that in a project you have requirements, developments and tests in that order. These activities apply under Agile methods as well.
In my experience (other experiences may vary…) the opposition is really between Agile (a well documented set of self reinforcing principles and practices) and the processes that managers have been empirically evolving for years after possibly learned from their mentors. It is much harder to make these people abandon their home grown methodology and do a leap of faith. It is much easier to help them evolve it by teaching things from the Agile toolbox, from engineering practices (TDD, CI) to useful metrics (Work in progress, inventory) to practices (Stand ups, retrospectives). Many of these tools have measurable positive returns and some are a small evolution from the existing ad-hoc practice.
The deadly poison here is to attach those tools to a specific methodology, unless the managerial hierarchy itself is pushing it (à la salesforce.com). A formal checklist of what is needed before a project can be called agile feels like a bad idea. We should instead thrive to put in place a well chosen set of the proven tools that Agile helped popularise. That will bring immediate benefits without a leap of faith. You may not be Agile in the end but you, your team and your customers will be happier.
It looks as if I would love to work there, although they probably would not hire me…
See their post with a link to the slides.
I will try to avoid making excuses from now on.
A very nice hands on roadmapping workshop at the BayAPLN yesterday. This was a very successful meeting where members got to practice roadmapping on our very own community.
Thanks again to the CoCo and Scott from enthiosys for making it happen.
In particular check out the templates they provide. I started practising today on the simplest template and we will see how that turns out.
I even got lucky and won a book at the raffle !
