The ATMAN Blog

Well, sorry, ’cause at least so far we don’t.

Mary explains why.

When we conduct the Portfolio Management Health Barometer and ask the statement about incentive systems we quite often run into people who start to ponder that the incentive systems should be so that they better reward individual performance.

But it’s a dangerous path to take. Listen to this TED talk discuss the issue in 19 minutes. Ville Heikkilä from our team ran into it via Henrik Kniberg’s blog.

Reko’s Bachelor’s thesis on requirements traceability in agile/scrum has now been posted on the Publications & deliverables page. Get it here (PDF, in Finnish).

We recently got a hold of Johanna Rothman’s new book Manage Your Project portfolio. It’s the best book we’ve so far found on the subject of matter of ATMAN. The fastest way to get hold of a copy is to purchase a DRM-free PDF from the publisher’s site.

The book is excellent in recognizing that portfolio happens (and should happen) on many levels, and gives lots of practical advice utilizable by individual developers, middle and senior managers alike.

As researchers we are somewhat puzzled that the author refers to all of these levels are referred to as ‘project portfolio management’… but then again, the contents are very readable, so the structural fuzziness does not really bother.

Anyhow, be sure to get a copy!

I follow InfoQ website and newsfeed. Usually, the things written there are at least interesting, if not informative. However, the Kanban hype is starting to reach such levels, that I just cannot let this article be. First, most of the arguments are really straw men, as I’ll show later in this post. Second, why the need to antagonize Scrum?

So, here are the 5 right reasons to implement Kanban, and why they are wrong.

1. Ability to release any time.

Really, how often you need to make a public release of a software without knowing it well in advance? If this is common occurrence in your organization, you are doing something wrong. (Hint: Public releases are planned and scheduled based on business and marketing reasons.) Maintenance (bug and issue fixing) is completely another ballgame, but even there constant updates might annoy customers.

Even if you must suddenly make a new public release, Scrum provides you with the result of the previous sprint. Considering that sprints are usually 2-4 weeks long, you just release something that lacks the improvements from a few weeks of work (which, in the grand scale of things, is not that much). Or you could wait a few weeks and release after the current sprint ends.

2. Ability to change priorities on the fly

If you allow constant changing of priorities on the fly, the priorities will change constantly. See point 3 for why this is a bad idea. The reasoning is also specious for the same reason as in point 1: If you cannot wait until the end of current (2-4 week) sprint to alter the priorities of user stories, you have a problem in your prioritization process.

3. No need for iterations

There is couple of reasons why considering only one user story at the time is a bad idea. First of all, it unavoidably results in emergent architecture, which, I believe, is nowadays consider nearly universally a bad idea. One of the less understood benefits of Scrum iteration and release planning is the possibility make informed architectural decisions based on the near future of the software. The second reason is the sense of commitment, urgency and accomplishment iteration and release paced work creates. Unless you have very mature and committed team, “it gets done when it gets done” attitude might take over in Kanban (see also point 4).

4. No need for estimates

Business people (marketing, management, etc.) will require estimates. If you are not required to provide any kinds of estimate on when certain set of functionality is done (it’s that bothersome public release planning again), you are working in a very special environment indeed. And, if you don’t even estimate your tasks, there is no commitment or pressure to finish them. Highly committed and mature team is required to avoid slacking off. Estimating also provides an opportunity to discuss and clarify user stories and tasks and facilitates discussions on architectural tradeoffs.

5.  Perfect flow visualisation

This is the strong point of Kanban (considering the method’s name, not a huge suprise), and I agree that it is a very usefull tool. Actually, you could easily use (an it is used) Kanban-style board for visualizing the progress of your sprint’s tasks in Scrum (instead or in addition to sprint burndown chart). The problem here is, that if you have only one user story (and no tasks) you develope at a time, you don’t really need Kanban board! Just stick one story at the time to the nearest wall and start hacking away. Somehow I feel, that the whole supply-chain management by pull process aspect of Kanban is getting lost here.

The original article, while being somewhat marketing-oriented, adds some disclaimers and is quite a bit more sensible. Do read the comments of the original article also!

A new article co-authored by Vähäniitty has been posted on Agilefant.org’s Related Work page: Lehtola, Kauppinen, Vähäniitty & Komssi: Linking business and requirements engineering: is solution plannning a missing activity in software product companies? Requirements engineering journal, Special issue RE’07 best papers, Volume 14, Number 2 / June, Springer-Verlag 2009

Check it out, and download your copy!

Forget about agile (if you already haven’t). Forget about lean. Kanban is here!

I mean, you did try Scrum and it didn’t work?

At least you tried daily stand-up meetings?
No?

You did have a backlog of prioritized user stories?
Really?

And a product owner who is always available and empowered to make prioritization decisions?
No time?

A long term plan of  software releases to guide prioritization and architectural decisions?
But thats not agile, right?

But you did split your user stories into tasks in the beginning of each iteration before starting development?
Waste of time?

Iteration burndown to display progress?
Hard to do without task effort estimates?

Retrospectives to identify impediments?
Is that even a part of Scrum process?

Well, at least you  had iteration demos after each iteration?
Nothing ready for a demo?

But you did try Scrum and it didn’t work.
And Kanban certainly will work.

(However, if you are interested nevertheless, here is a link for you.)

What happens to architects when a medium-to-large SE organization decides to adopt agile practices enterprise wide? The architects might be integrated to development teams, but agile software development methods do not remove the need for high level architectural design for system-wide components and frameworks.

While agile is all about empowering the team, some times high level architectural guidelines are needed. For example, three teams developing three components of a large web-based system might decide to use three different frameworks. One team decides on Ruby-On-Rails (because it is new and cool), second decides to use Perl and SQL (the system they are most familiar with) and third decides on Spring (they know only Java). This would, no doubt, result in horrible mess when the three components are integrated. Similarly, a effective high level component architecture of a complex system does not simply emerge from the individual teams responsible of the individual components.

You don’t necessarily need to have a separate team of software architects, as a virtual team of architects from each of the agile teams could be used. Just remember to allocate time for the high level architectural work.

Two new articles outlining have been posted on Agilefant.org’s Related Work  page: Long-term Planning of Development Efforts by Roadmapping – a Model and Experiences from a Small Software Company (in proceedings of Euromicro SEAA 2009) and Small Software Organizations Need Explicit Portfolio Management (forthcoming in IBM journal of Research and Development).

Check them out, and download your copies!

Our paper was accepted to Software Development Governance workshop at ICSE 2009. The workshop is now arranged for the second time and we are happy to participate again. Link to full paper.

Software Development Governance Challenges of a Middle-Sized Company in Agile Transition

Ilkka Lehto & Kristian Rautiainen 

Abstract

We studied how a middle-sized Finnish company
employing agile methods governs its software product
development. Through observations and interviews we
followed the trace from strategic plans in the form of
roadmaps to various backlogs and all the way to daily
work. The governance roles, responsibilities and deliverables
seemed to be in place on different organizational
levels. However, closer inspection revealed
challenges in the practical implementation. There were
too many roles and hierarchy levels with information
consistency problems in between. Prioritization of the
high-level goals was unclear and made it difficult to
plan and organize development work based on business
value. The trace from high-level goals to more
detailed plans was easily corrupted due to poor planning
practices. Progress monitoring of daily work was
poorly done and not linked to high-level plans. Consequently,
the required feedback loops were inadequate,
making it impossible for management to take corrective
actions in time.