Category: Organisation

Thoughts About Scrum

Since now more than a decade, lightweight methodologies and processes have flourished under the umbrella of the Agile movement.

Despite the claimed success of Agile from daily practitioners, I haven’t seen many researches showing evidence that the Agile concepts really worked as expected; by this, I mean that Agile could still lead to reproducible success, but for other reasons that the one pushed by the various methodologies.

Here are a few open questions, especially about Scrum, for which I couldn’t find a decent answer. (For other related digression of mine, see real-world software development methodologies and What is a feature?)

Wasting time and unnecessary pressure

Scrum is organized around the notion of product backlog. One central notion in Scrum is that once started, the priorities of the current iteration won’t change; developers can focus and organize their work according to what’s been decided to go in the iteration, without being constantly disturbed by changes.

When a necessary change is detected, we tend to perceive it as highly prioritary: “We absolutely need this and that as soon as possible”. The existence of the product backlog and the frozen iteration improves this situation. Any story can be added anytime to the backlog. The priority of all stories will be reconsidered together when the next iteration starts. The process itself then promotes some relativity in the decisions that are taken, which is welcome as to lower the unnecessary pressure that is frequently generated.

Even though I heard this from a Scrum practitionner, I never found any evidence of this. It would however be possible to mine product backlogs to verify whether the priority of the stories tend to follow the scheme mentioned above: most of them are first entered with high priority, which then lowers over time. Only few stories are really prioritary, and the process helps their selection and identification (we could say the the signal-to-noise ratio is improved).

Delivering added-value

Another pillar of agile methodologies is to move away from technology engineering to product engineering. The team should focus on what brings most added-value – what make the software valuable – instead of what constitutes the software technically.

We see this tendency in several concepts:

  • Scrum has a user story, which is the expression of a valuable feature from the point of view of the end-user.
  • FDD has features, expressed in the form “<action> <result> <object>” (e.g. Calculate the total of a sale), which directly represents the value of the feature as perceived by the end-user.
  • TDD is less clear about this (and I’m not even sure if it’s considered as agile). Still, a test case can be perceived as the expression of a comprehensive feature.

While nice on paper, it’s not always easy to organize the development according to only added-value as perceived in the final product by the end-user.

For instance, the possible asymmetry between the complexity of the user story vs. the complexity in term of development effort, may impose a user story to be broken down into technology-related tasks.

The internal development tasks also escape the added-value scheme. A refactoring has no added-value from the customer point of view. How is then internal development effort managed in the context of agile methodologies?

I never found any clear positioning of agile practitioners regarding such problems. An analysis of existing backlog or issue trackers would be valuable to provide an explanation about how people manage this.

The case of bugs

Shipping a software product with no bug is an illusion. Bug reports,  bug triage and then bug fixing is part of the software development process.

Bugs and defects do however not fit very well with most agile methodologies. Should the user story or feature be reopened when a bug is reported? Should the bug be wrapped in a new story or features?

There isn’t lots of description of how the main development effort and the bug handling fit next to each other.
A study of how this happens in practice, both from point of view of the process but also from point of view of the tools (e.g. do most company still have an issue tracker to let customer report defects) would be interesting.

How agile are you?

The central point to agile, is well, to be agile. That is, to be able to adapt rapidely to changing requirements or situations. This stems from the fact that we can not anticipate everything, and that we can actually only anticipate very little when it comes to software development. And it’s a lot more rewarding and effective to improve the ability to face  changes than to desperately attempt to improve our ability to predict the future.

That said, there is no metrics for the “agility” of a team. It would however be interesting to define such a metrics (even if not a really tangible one) to be able to track progress in term of agility. Such a metric could be based on a mathematical model of how long user stories remain in the backlog.

Conclusion

Despite the wide acceptance of agile methodologies and the apparent success of these one, how they are really used in practice remains vague. It is especially hard to know how much the actual processes diverge in practice from the somehow theoretical vision of each methodology.  The methodologies do also not always address the whole spectrum of the software development lifecycle, in which case companies are probably introducing ad-hoc customizations and rules to cover their needs.

Getting Things Done 3.0

I started reading Getting Things Done, but then dropped it. I nevertheless quite enjoyed the points about (1) building an organizational system that we trust and (2) doing the action immediately if it takes less than 2 minutes (which I had heard many time before but didn’t know it came from this book).

The book is a bit old fashioned to me. We can argue that the concepts are general, but we are information worker now and the “basket” mentioned in the book have been replaced by web applications, USB keys, and iPhone.

Building then a modern organizational system that we trust is far from easy. We need to balance different dimension that impact our trust in a system, e.g. security, reliability, perennial data format, etc. Well, the usual non-functional requirements.

Ultimately, it’s a matter of time and risk: How long will I need to re-do the work? What are the consequence if I forget this or that?

In my previous job in an ECM company, I increased my awareness about such issues. Managing the massive amount of information produced nowadays is a challenge and business case. I remember I was astonished when I read these numbers for the first time:

Recent estimates show that a typical worker will take 12 minutes to process a single document. Nine of these 12 minutes are spent searching for, retrieving and refiling the document — meaning that only three minutes are spent actually using the information they’ve found.

The average office:
• Makes 19 copies of each document.
• Spends $20 on labor to file each document.
• Loses 1 out of 20 office documents.
• Spends $120 searching for every misfiled document.
• Spends $250 recreating each lost document.
• Spends $25,000 to fill a four-drawer file cabinet and $2,000 annually to maintain it.

The volume of paper documents that organizations must process has increased tenfold in the last five years. Increases in paper volume drive the cost of paper handling higher, which greatly reduces profit margins.

(from Document Management Overview.)

And for the story, I tried first to find this excerpt using a search for “Introduction to enterprise content management” on my hard drive. No result. I then decided to locate it manually. I went to Library > Intranet, communication & ECM and … it was there! It’s funny that even though I recalled what the book was about, the name “Document Management Overview” was completely different from what I tried. Ontology ftw!

Here is what composes my current organizational system:

Topic Decision Inception year
Email – Three mailboxes: one personal, one professional, and one for garbage.
– Redirection address @a3.epfl.ch as the default for long-lived communication (e.g. contact)
– BCC myself in email (2012)		 2004
Source code – < 2010 self-administered subversion, assembla.com for private projects
– 2010-2013 Google code
– 2013+ Github		 2005
Archival – Convertion of esoteric format (.eps,.pic) to PDF
– Recording of minidisc and super8 into .mp3 and .mov		 2005
Online CV – LinkedIn (since 2005)
– Stackoverflow (since 2010)
– Xing (since 2013)		 2005
Application and S/N – Store the serial number in the same location as the application 2006
Backup strategy  RAID drives is not enough if I delete files by mistake.
– incremental backup on CD/DVD
– complete backup on external HD
-TimeMachine since 2012		 2007
Digital music and picture – Not in the cloud
– iTune for digital music (since 2009)
– All pictures organized by date and periodic backup
– Gallery with Lightroom on personal website–
– DropBox for picture sharing (since 2010)		 2007
Information overload – In case of too much information piles up, I gargabe collect according to these rules. 2008
USB keys Be disciplined, copy the information on a computer asap and clear the key 2008
Agenda, birthdates and contact – Google Calendar
– Goolge Contact		 2008
Web identity and avatar – Avatar on gravatar
– Two usernames: ewernli and wrnli		 2008
Bookmark – Bookmarks are personal
– Usage of Foxmark with centralization on my server (not in the cloud)
– Organized in a taxomony / since 2013 with tags
– Pocket app (since 2017)
 2008
Place to visit, music to listen, movie to watch – Various Google Documents
-IMDB and Jini for movies (since 2013)
-Goodreads for books (since 2013)		 2009
Other To Do – Leverage Google Calendar for actions which have deadline
– iPhone Reminder App		 2009
Random thoughts – Twitter
– 2013 self-administered blog with Liferay
– WordPress blog (since 2013)		 2009
News and RSS – Google Reader
– Feedly		 2009
Scientific literature – Usage of BibDesk as master copy
– CiteULike (until 2017)
– Mendeley (since 2017)		 2009
Password and login – Password-protected excel spreadsheet 2011

Getting Things Done is to business what No Broken Window is to software development. Whenever something comes in that requires some action, either do it right now, or at least enter it in a reliable system for later (In the case of development, the system is of course the issue tracker).

More Links

 

Keep your desktop clean: a checklist

I found a post-it on my desk this morning that was actually there since several months (if not year). It’s a short checklist with questions to answer before deciding whether I will trash or retain a document.

I tend to retain too many documents (electronic and paper)  that consumes space and are useless — I will anyway never read them. This short post-it helps me in my cleaning activity. It helps me take some distance with the material and its importance.

  • is it hard to find the document again?
  • is the document important regarding legal aspects?
  • is the document up to date?
  • is the document currently/frequently used?

Then if all answers are “no”, trash it!

It’s amazing how many documents can actually be trashed according to this checklist. Free desktop again!