Viewing entries in
Software Development

Comment

Successfully bootstrapping a large scalable Scrum practice at Royal Dutch Shell

Today, I will be presenting my paper at agile 2012. Here is the abstract for this work:

We will present the saga of a successful transformation from a struggling software development group to a scalable Scrum practice within Royal Dutch Shell. This group of sixty individuals encountered many obstacles on their journey to carry on the development of a large, 25 year old, legacy application. You will see how, over two years, we implemented a set of organizational, technological, procedural, and cultural changes to lead this group forward. Finally, we will present our vision to further strengthen and accelerate this value delivery system.

You can download the slide deck and the article itself.

Comment

1 Comment

Automating unit testing is difficult but that's no excuse

In this short article Rob Diana argues that developers are responsible for producing working code and that to do so, it is imperative that the code gets tested and exercised through unit tests. This is perfectly reasonable and most developers I worked with don't have any issue with unit testing as defined by Wikipedia as long as the level of automation is low or non-existent. The Wikipedia article on unit testing explains that "[unit testing] implementation can vary from being very manual (pencil and paper) to being formalized as part of build automation."

However, a major gap exists between exercising the code through manual or semi-automatic tests and writing automatic tests to verify continuous integration builds. Of course the latter produce higher quality software in the long run but this gap prevents some teams from reaching a higher level of code quality while minimizing rework (i.e. higher productivity).

Implementing automated unit tests is not simply a technical exercise. It is also a complex problem that requires a sophisticated and coordinated effort among developers accompanied by a culture change where developers and other stakeholders:

  • treat unit testing code with the same level of respect as the rest of the application (this code may not end up on the server or the user's desk put it is an essential element in minimizing defect escape rate);
  • accept that an automated build is successful, if and only if, all the associated unit tests passed.

This combination of cultural and technical changes is essential to a successful and full-scale automated unit testing implementation.

1 Comment

1 Comment

Things to think about before and after a daily stand-up meeting

Daily stand-up meetings are at the core of the Scrum process. They help synchronize the team and quickly escalate impediments. Regardless if you have been participating in those meetings for years or you are just starting today, Mike Griffiths just published two useful posts to help us get more out of this critical activity:

1 Comment

Anchoring Effect

Comment

Anchoring Effect

Anchors

According to wikipedia:

Anchoring or focalism is a cognitive bias that describes the common human tendency to rely too heavily, or "anchor," on one trait or piece of information when making decisions.

This is a dangerous bias that can bite you when you are estimating tasks or stories in an Agile environment. I am even wondering if this plays a role when you are poker planning, and how much this influences your decisions from the get go.

Anyway, this article goes into detailing the anchoring effect and the "You are not so smart" blog is providing insights on common human behavior that plays an important role in software development.

While the phenomenon is well-known, I am wondering what a team can do about it. How can you overcome its nefarious effect and also how do you measure its effect in the long run.

[via You are not so smart]

Original photo by Plbmak

Comment

Comment

Agile Anti-Patterns

I believe that Agile is a great tool to help development teams achieve more, improve, and reach their next level in effectiveness, productivity, or creativity. However, like any tool, it can be misused or misapplied. You can shoot yourself in the foot if you are not applying a certain level of discipline or hygiene.

Mike Griffiths posted a short and sweet article on this subject that he entitled Agile anti-patterns. He classifies those anti-patterns as follow:

  1. Agile as a silver bullet
  2. Agile as an excuse for no discipline
  3. Agile without explanation
  4. Shallow Feedback

Comment

Comment

A crash course in modern hardware

If you have not reviewed lately how modern CPUs operate and how they differs from CPUs that you grew up with, you may want to watch this video. It is quite long but certainly instructive. You will learn about what impacts performance today and how Donald Knuth was right all along. :-)

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" — Donald Knuth

Comment

1 Comment

Frequently Forgotten Fundamental Facts about Software Engineering

In this article, Robert L. Glass, list principles, facts related to software engineering. The list is organized onto the following categories:

  1. Complexity
  2. People
  3. Tools and Techniques
  4. Quality
  5. Reliability
  6. Efficiency
  7. Maintenance
  8. Requirements and design
  9. Reviews and inspections
  10. Reuse
  11. Estimation
  12. Research

I encourage you to read this article regardless if you are new to the field of software engineering or a long timer. Sometimes it is nice to be reminded of the "law of physics' regimenting our discipline.

[via IEEE]

1 Comment

Comment

Skepticism in Software Development

I just read an article from Jason Gorman, from Parlez|UML, on skepticism in software development. He explains that a lot of preconceived theories about software development abound but few of those theories have been thoroughly investigated and therefore, it is difficult to know if they bring value to the engineering process or not. For example, Jason mentions refactoring that claims to make changes easier without supporting research. In my understanding, this leads to more academic research on those theories to validate them and also to explore their practical boundaries and limits. I believe that this is a perfectly valid, and necessary approach.

However, in parallel to this academic approach, I would have a tendency to take a more pragmatic route. If a concept like refactoring comes to my attention, I would try it out in my environment, see if it has value to my organization and decide, after retrospective, to continue using the method or not. Also, you can not detach the software engineering method or principle from the human component. The method, under properly applied leadership,  has to be accepted and embraced by the programmers, testers, or UX designers that would use it. Therefore, the development team, including its lead, decides, if a particular theory helps bring more value to customers.

[via Parlez|UML]

Comment

Comment

Object Oriented Programming: Law of Demeter

ur-ban.com has an article describing in details the Law of Demeter. The law states that a method M of and object O may only invoke the methods of the following kind:1. a method on O itself 2. any parameters passed to M 3. any objects instantiated within M 4. any direct components of O

[ via ur-ban.com]

Comment

Comment

Scrum or Kanban? Pick One And Get On With Delivering Quality Code!

Jason Gorman is pesting about the fact that some individuals in the Agile community are obsessing about project management and applying specific methods. He suggests that energies should be directed at delivering quality code instead since this is much harder to master that the simple Scrum or Kanban methodologies. He is right on.

Speaking of Scrum and Kanban, you may also want to read my previous post.

[via Parlez UML]

Comment

Comment

Kanban - The Next Step in the Agile Evolution?

I am interested in everything that can help improve my teams' productivity and consequently helps us provide better value to our customers. As such, I have started reading about Kanban, a project management methodology that appears to "compete" with Scrum. Scrum is the methodology that I am currently using. Scrum is an iterative method that provides incremental value to stakeholders at the end of each iteration. The product owner provides requirements at the beginning of each iteration. During the iteration, the team designs, implements, tests, documents, debugs new features based on those requirements. At the end of the iteration, the team demonstrates the new features to the product owner who accept or reject them.

Kanban on the other hand, is not an iterative process. The product owner provides ranked list of requirements. The team pulls requirements from top of the list one at a time. The team designs, implements, tests, documents, debugs new features based on those requirements. The product owner review the new features as soon as they are produced.

Project Management Hut presents an article describing Kanban as the next step in Agile Evolution.

[via The Project Management Hut]

Comment

Comment

Introduction to Distributed Source Control

Today, ytechie has posted a good introduction to distributed source control. It is nice to see that we now have more options when it comes to SCM. While I can see the need for distributed source control systems in large projects like the Linux kernel or FreeBSD, I have found over the years that with the evolution of broadband around the world, bandwith is no longer a bottleneck and it is possible to use a centralized source control system with teams working on different continents.

In addition, I am wondering if distributed source control systems would have a tendency to impede continuous integration as individuals are no longer obligated to check-in their changes in the central repository.

I am interested in your comments. Do you have experience with Distributed Source Control systems and do you feel that they have helped improved your productivity?

[via ytechie]

Comment

Comment

Two worthy Agile methodologies articles

Here are two Agile articles that I found interesting, and would like to share with you. On his blog, Kai Gilb has started a series of posts entitled "7 truths about Agile and Scrum that people don't want to hear" The first part, Wrong Focus, describes how developers should focus on providing value to stakeholders rather than creating software for the sake of developing software. It also states that the Agile Manifesto may be a cause for this wrong focus. For my part, I believe that while the creation of value falls in the developers realm, the definition of this value and its correlation with the stakeholders wants and needs is the responsibility of the Product Owner. Kai's article is very good and I am looking forward to the six other parts.

In another seven posts series, Jack Milunsky introduces us to Lean Development and describes how seven manufacturing wastes (In-process Inventory, Over-Production, Extra Processing, Transportation, Motion, Waiting, Defects) matches wastes in software development (Partially done work, Extra Features, Relearning, Handoffs, Task Switching, Delays, Bugs). His articles are well structured and informative.

Comment

Comment

Stack Overflow

StackOverflow Home Page

If you have not seen StackOverflow, I encourage you to get familiar with it right away. It is a great resource for software developers among us. The site went in public beta two weeks ago and it is basically an hybrid between a wiki, a blog, digg, and a forum specifically dedicated to answer programming questions.

It is self-moderated and it works. Questions are answered in a matter of minutes and noise is quickly eliminated. It is fun to try to answer questions and it is certainly an humbling experience as many out there are much more savvy than I am.

Comment